I have a problem maintaining UP a EoIP tunnel between 2 routers.
eg.
R1 - multiple IP addresses on Wan Interface
10.0.0.16
10.0.0.120
10.0.0.250
EoIP tunnel - Local Address: 10.0.0.120 / Remote Address 192.168.0.10
R2 - single IP Address
192.168.0.10
EoIP tunnel - Local Address 192.168.0.10 / Remote Address 10.0.0.120
After a few hours, the packets from R1 arrive at R2 with IP 10.0.0.16, not the one specified in R1 EoIP config, so at R2 does not accept the connection.
Someone else had this problem?
Could someone replicate this?
Haven’t had this problem, but I can imagine there is one src-nat (masquerade) rule too much or one too few.
The firewall connection lifetime for GRE protocol (used to carry EoIP packets) is 10 minutes. So if there is a masquerade rule on the R1’s WAN, it may assign the 10.0.0.16 as source address to the first R1->R2 EoIP packet which is sent 10+ minutes after the last EoIP packet in any direction was seen. If the very first packet after the tunnel gets up goes from R2 to R1, the masquerade rule at R1 doesn’t act so the tunnel works fine as long as the connection is constantly updated by ongoing traffic.
If the above is not the case and there is a random glitch, an action=srcnat rule at R1 might be used to hide it: the connection tracking will deem a packet mistakenly sent from 10.0.0.16 to be the first one of another connection, so it will src-nat it to the proper src-address (10.0.0.120) expected by R2. That rule has to be selective and only match on protocol=gre out-interface=WAN dst-address=192.168.0.10. The question is, though, whether the R2->R1 packets won’t get “un-src-nated” upon arrival, and if they will, whether the EoIP at R1 will accept them. This may even depend on the order of the two connections in the connection tracking list, so you have to test the actual behaviour.
Thanks for response, but you were misled by the IP’s. Those IP are public IP’s. So NAT it’s not involved, only input/output chains.
I’ve used private ip’s only for explaining purpose.
Just a short comment. Those IP’s on R1, are on the same interface.
What I wrote does not depend on whether the three IP addresses on the same interface of R1 are public or private, and yes, I’ve noticed that all three are on the same interface.
If there is currently no src-nat/masquerade rule associated to that WAN, that means one possible source of the issue less, which is good.
In addition to adding a src-nat rule to “fix” the wrong choice of source address as I’ve suggested yesterday, it might help to add a dedicated route towards R2’s IP at R1, and set its pref-src to the desired source address of the EoIP tunnel. Both are just workarounds, as the actual reason why the router all of a sudden decides to start using another address is not known to me. Are the addresses assigned manually to the WAN? Because if the desired source address becomes unavailable for a while for any reason, the EoIP may use an available one instead, and possibly routing cache may cause it to be used for a while after.