[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ipmasq (iptables), pppd and changing ip address



Hallo,

The first TCP connection that is triggering pppd to dail (on demand) is always getting an error (timeout). Following TCP connections are OK.

I am using Sarge (3.1r1) with kernel 2.6.8-2-686.
I have an ethernet card (eth0) for my local network. This is a small network with only two other computers. I have an ISDN card with CAPI and pppd configured (ppp0) to dail on demand. I am getting an IP address asigned for my ppp0 interface by the provider. This IP address is changing every time I am dailing. I have installed ipmasq for masquerading the internal network and using the default configuration of ipmasq. Part of the rules Ipmasq is using are shown here:

#: Masquerade packets from internal networks
/sbin/iptables -t nat -A POSTROUTING -o ppp0 \
	-s 192.168.15.1/255.255.255.0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o ppp0 \
	-s 192.168.15.1/255.255.255.0 -j ACCEPT
/sbin/iptables -A FORWARD \
	-m state --state RELATED,ESTABLISHED -j ACCEPT


I think that I understand the problem. In the case that pppd has hung up the phone, then the routing table, the iptables and the ppp0 interface all have the old ip address. when I now want to make a new TCP-connection, the first packet passes the routing table and the iptables and gets masqueraded for the old ip address. Now pppd gets triggered and dials the provider to send the packet. It gets a new connection to the provider and sends the packet (all OK). In the mean while, pppd has got an new ip address an updates the routing table and the iptables for this address. Now a response is comming back for my packet but with a destination address of my old ip address. This ip address is now blocked by the iptables. This results in a timeout for this TCP-connection. All the following TCP-connections go through without problems because all the tables are set up correctly.

Does anybody have the same problem or has found a solution to it?

Thanks,
Vincent Smeets



Reply to: