Modify

Opened 4 years ago

Last modified 3 years ago

#15779 new defect

MASQUERADE fails after some time for a single connection

Reported by: hauke@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: iptables masquerading Cc: hauke@…

Description

After quite some time (weeks, maybe even months) iptables' MASQUERADE fails for one UDP connection (OpenVPN). OpenVPN does not run on the router, the connection is just routed.

tcpdump shows that the packets are sent out with their private source address:

root@OpenWrt:~# tcpdump -i pppoe-wan -n udp
03:49:19.901230 IP 192.168.1.2.1194 > 217.92.x.y.1194: UDP, length 60

All other connections are not affected. "conntrack -L conntrack" shows the connection.

This has happened with my former version of OpenWRT, too (Backfire, I guess). A reboot solves the problem; restarting iptables does not. I guess the problem even disappears after some time (if no more packets of this connection are sent).

Attachments (0)

Change History (10)

comment:1 follow-up: Changed 4 years ago by anonymous

How does this problem appear, or what are the consequences? I had OpenVPN problems since half a year now with three of my OpenWRT routers, and I never figured out until today, what the reasons for these are. I use two VPN connections on each of my three routers, and randomly the connection of the VPN "break down". The OpenVPN connection is still up, you can ping the server, but no packets arent coming back anymore which are routed outside of the lan itself. I have to close and reopen the OpenVPN connection, and a few minutes later it mostly will happen again, until it somehow becomes stable for days, weeks, or even a month again. I tried TCP and UDP OpenVPN though and both show these symptoms.

comment:2 in reply to: ↑ 1 Changed 4 years ago by hauke@…

Replying to anonymous:

How does this problem appear, or what are the consequences?

As I wrote: These UDP packets are not passed to the Internet with source address 1.2.3.4 (WAN address) any more but with 192.168.1.2 which is obviously not routed on the Internet. In consequence the VPN breaks down.

The OpenVPN connection is still up, you can ping the server,

I cannot ping the server through the VPN any more but I guess it would be possible the other way round. I can ping the VPN server outside the tunnel, though. I can connect to it with SSH, too.

I have not tried yet (and the problem is obviously difficult to reproduce) whether all UDP connections to the same host are affected.

My advice to you is: Use the tcpdump call I gave when your problem occurs to check what your VPN packets look like on the WAN interface.

comment:3 Changed 4 years ago by anonymous

Any idea whether this can also happen under the latest Barrier Breaker trunk ?

comment:4 Changed 4 years ago by Damian Kaczkowski <damian.kaczkowski+openwrt@…>

It happens in BB too. It is probably bug in upstream iptables. Try to report this bug to iptables developers.

Anyway, It was fixed in openwrt by dirty workaround some time ago (by flushing conntrack on every if{up,down} event), but it seems that the workaround was dropped after switching to netifd.

Read here for more info and manual workaround: https://dev.openwrt.org/ticket/10225#comment:5

comment:5 follow-up: Changed 4 years ago by jow

See if you have a conntrack rule for your VPN server in /proc/net/nf_conntrack when you experience the problem. I too think it might be a variation of the #10225 bug.

We dropped the dirty workaround in favor to a cleaner approach. The current firewall will set the policies to DROP while rebuilding the ruleset so that no packets can reach conntrack in the brief period where the router has its "pants down", this can fail however if there are custom scripts or rules interfering with the firewall operation.

comment:6 in reply to: ↑ 5 Changed 4 years ago by hauke@…

Replying to jow:

See if you have a conntrack rule for your VPN server in /proc/net/nf_conntrack when you experience the problem.

Indeed. "conntrack -G conntrack -p udp -s 192.168.1.2 -d 217.92.x.y --sport=1194 --dport=1194" shows an entry. Deleting this one "solved" the problem.

But I don't get it: Why should such an entry prevent the according packets from being SNATted? Must be a strange bug.

The current firewall will set the policies to DROP while rebuilding the ruleset so that no packets can reach conntrack in the brief period where the router has its "pants down",

Makes perfect sense to me from a security perspective but why should this cause problems with masquerading? Or does that just happen to prevent triggering the bug?

this can fail however if there are custom scripts or rules interfering with the firewall operation.

Not in my case.

comment:7 Changed 4 years ago by jow

The underlying issue is that MASQUERADING is only applied to new flows which have corresponding entry in conntrack yet. The old bug #10225 quoted above was due to packets reaching conntrack while masq was not set up, so netfilter remembered an active connection that was not natted and did not apply masq to it.

I'm not sure if its the same situation in your particular case.

comment:8 Changed 4 years ago by anonymous

Apparently this is still a problem (typically becomes apparent with UDP flows):
https://forum.openwrt.org/viewtopic.php?id=51871

One solution requires (recent) conntrack:
conntrack -D --src-nat --reply-dst old.wan.ip.addr

​Related: http://serverfault.com/questions/367626/delete-specific-conntrack-entries

comment:9 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:10 Changed 3 years ago by anonymous

jow added the fw3 part of his solution for flushing old states upon WAN ip change and asked for testing:

jow wrote:
r42114 (http://nbd.name/gitweb.cgi?p=firewall3.git;a=commitdiff;h=2807cc26b8e46eef5f23c06534a853dd48183331;hp=91953d6a6e90df988f442f53097bd208784a295d) should resolve this issue by clearing out conntrack entries that refer to the old wan ip. I'll keep this ticket open until more people confirm that it is working properly, I cannot test it under real life conditions since my cable ISP always hands out the same address.
If the fix is confirmed working I'll backport all required parts to BB.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.