Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

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.
share|improve this answer
    
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 '09 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 '09 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 '09 at 11:12
add comment

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

share|improve this answer
    
The IP is static :( –  andi Aug 13 '09 at 16:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.