Hi,
I have a HAP AC with effectively two logical Internet interfaces.
One is a physical link from eth5 to an SXT LTE router, that’s set up in the laziest way with double NAT, so eth5 has DHCP client and adds a default route with distance=2.
The other is an L2TP logical interface that goes via the LTE Internet to a provider and gives me a static IP address. That interface has a default route distance=1 so when that L2TP connection is enable and connected, it is the preferred Internet route.
All good so far, except that my Gigaset IP phone does not register when it routes over the L2TP.
Taking a packet capture from the L2TP interface I can see traffic from my Gigaset is getting NATed not onto the interface address of the L2TP, but onto ether5 address instead. However if I ping from my desktop PC which is on the same LAN subnet, to the same destination IP address, I can see it being correctly NATed onto the L2TP i/f address.
Any ideas? The NAT configuration is as simple as can be, in fact unchanged from Quick Set, all I did was add the L2TP into the WAN interface group.
> ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
I’d be less puzzled if it didn’t work at all, but to work for everything except one particular internal host is bizzare.
Any ideas?
Thanks, Tony S
I don’t know why this issue was arising for just one particular host but I think I’ve fixed it by brute force. Firstly there was no good reason other than laziness for the double NAT on the LTE connection so I’ve changed that to a routed connection, and on the main router moved ether5 out of “WAN” and into “LAN”. So that path only has NAT at the LTE router. The main router still does NAT for the L2TP of course.
Looking under IP / Firewall / Connections I could see connections from the Gigaset which still had ether5’s address as their “Reply src addr”, as if NAT was still in effect (and still wrong because of course these should have the L2TP as their NAT address.
So what it appears to mean is that once a NAT entry is setup that mapping is retained, even if that route changes. For this host only.
There doesn’t seem to be a way to clear the NAT table and let them reestabilish (“clear ip nat tran *” in Cisco speak), However I could remove the connection entries individually. At first these were replaced by entries without NAT at all, showing the original host address as “Reply src addr”. After removing these as well it eventually did the right thing and started forwarding these packets with correct NAT.
So it’s working but I’m not sure what to conclude. Clearly this sort of stickiness in the NAT is going to be a problem with failover between different ISPs. But it seems to only affect that one host, could that be because it’s solely UDP? Do UDP NAT entries have a rather long timeout, or maybe the timeout is reset by any packet with the same original source/destination, even if it now routes differently so the NAT is no longer appropriate.
Did a bit more testing and I can see that this would definitely stop proper fail-over operation.
What’s happening in a failover situation is that the Mikrotik is correctly re-routing the traffic based on the preferences in the routing table. However it is hanging onto the previous NAT status for the connection even though that’s now incorrect for the new route.
Should I have more specific NAT configuration, maybe now we only have one path where it should be applied should I name the specific Interface? At the moment it just specifies “out-interface-list=WAN”. Although in fact the WAN list only has one interface in it anyway.
Once an entry exists in the connection tracking table, along with any associated NAT flags, that’s it until the connection is closed. UDP connection tracking is tricky - as there is no equivalent of the TCP FIN flag to peek at, the “connection” is deemed to exist until no matching packets are seen for a certain period. For some services, typically SIP and NAT-T IPsec, the client keeps on sending packets so the connection tracking table entry is never cleared when the WAN changes.
There are many discussions in the forums going back over a decade, typically you need to detect the routing / gateway has changed and purge the UDP connection tracking entries, e.g.
/ip firewall connection remove [/ip firewall connection find protocol=udp]
Thanks, that sort of confirms what I was coming around to realising. For SIP the UDP “connection” will never timeout, the device specifically keeps it alive in order to allow otherwise unsolicited inbound signalling. I need to look at scripting, particularly triggering since that script isn’t something that could run periodically. We’re looking for a change, not for a status.