0

I have a machine that is connected to another host over a permanent GRE tunnel. I have put the machine behind a Linux firewall (Smoothwall), and NAT-ed all GRE packets to the machine, using the rules:

/sbin/iptables -t nat -A PREROUTING -p 47 --src $tunnel_server_ip -j DNAT --to-destination $false_ip
/sbin/iptables -t nat -A POSTROUTING -p 47 --src $false_ip -j SNAT --to-source $real_ip    
/sbin/iptables -t nat -A INPUT -p 47 -j ACCEPT

(see NAT GRE (IP protocol 47) over Linux router)

It all works fine, but after a period of inactivity on the tunnel, of approximately 15 minutes, I cannot connect from the internet to the machine over the tunnel. After I send any packet from the machine to the internet, ping, open a web page in a browser, the tunnel gets activated again. As a workaround I now use a cron script that starts curl to a page in the internet.

Please help me understand what causes the tunnel to stop functioning, and tell me what can I do to replace the curl hack.

2 Answers 2

1

You may be having problems with conntrack timeouts. I don't know if it is the case, it seems that your rules would suffice without using conntrack, but anyways, you may want to keep some traffic in the tunnel to keep it open. You don't need to load a web page using curl, a simple ping should suffice.

If you want to try with bigger conntrack timeout, try this:

sysctl net.netfilter.nf_conntrack_generic_timeout=7200
sysctl net.ipv4.netfilter.ip_conntrack_generic_timeout=7200

Other general notes:

  • It is generally good practice to add a -i <eth> argument to the PREROUTING rule, and a -o <eth> argument to the POSTROUTING rule. Avoids the rules to misfire and reduces the load to the firewall.
  • The INPUT chain rule is useless. Also, it makes little sense to use ACCEPT target in the nat table. Perhaps what you are looking for is a similar rule in the FORWARD chain of the filter (default) table.
3
  • This must be it. As you said, ping does fix the problem. Does this mean that the first rule is useless, and packets coming from the internet are forwarded based on the firewall memory tables?
    – andi
    Aug 13, 2009 at 16:08
  • it depends... you need to check if the rule hit counters (shown with iptables -t nat -L -nv) are increasing after each packet is received. If they are not, you need to check why, perhaps adding a logging rule (-j LOG) to check what are the packets that are not triggering that rule, and why.
    – Juliano
    Aug 13, 2009 at 16:18
  • Thanks for the hint with checking the hit count. The result surprised me: there are no hits on the postrouting rule, and there are many packets matching the prerouting rules. Next step will be to investigate which drop or reject rule increases the number of hits when the tunnel is not functioning. I will post results in a few days.
    – andi
    Aug 14, 2009 at 11:12
0

May be you have a dynamic or shared IP or and it is reallocated by your ISP?

If this is the case I'm fear you have to keep a similar hack

1
  • The IP is static :(
    – andi
    Aug 13, 2009 at 16:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .