Hi All,
In one customer project I got sporadic problem with masquerading at ppp0 interface. The simplified setup is as shown below:
Client PC <---------->Linux router<----------->modem<----------->ISP
The Linux router uses the kernel Version 2.6.22.19 and iptables v1.2.11.
The routing steps are dynamic as described below:
1) Client PC tries to send tcp sync to an internet server
2) The router recognizes these packets and creates a ppp0 interface for this session
3)after the ppp0 gets up, the router masks the tcp packets in the mangle table by iptables, defines a new route in e.g. table 44 (default dev ppp0 scope link) and add a new routing rule (32765: from all fwmark 0x3 lookup 44). The default GW remains eth1, not changed to ppp0.
4)at the same time the iptables filter table is extended to accept the marked packets and the masquerading rule for ppp0 interface is also added to the nat table (see below)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0
This schema works well typically with one exception: if the modem connection gets broken and is established again after several minutes, it happens sometimes that all new coming tcp packets from the Client PC afterwards will not be masqueraded although a new masquerading rule for the new creared ppp0 interface (with the old inet address) is added to the nat table again for the new session. In this case the client PC cannot get any tcp response from the internet server. This problem can only be solved by rebooting the router.
Does someone have an idea, what could be the reason for this problem? Can someone explain me the mechanism behind the masquerading for ppp+ interface? I mean where is the dynamic inet address of a ppp interface stored for masquerading purpose and how can the netfilter know that one packet is assigned to the ppp0 interface.
I would appreciate any help and information very much!
Best regards
Li
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
