Re: ipmasq (iptables), pppd and changing ip address
Ola,
Vincent Smeets a écrit :
The first TCP connection that is triggering pppd to dail (on demand) is
always getting an error (timeout). Following TCP connections are OK.
[...]
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 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.
That seems correct AFAIK.
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.
A response packet would match the entry in the conntrack-NAT table
created by the outgoing packet an would be seen as ESTABLISHED, so I
don't think iptables would drop it. But actually you won't even receive
any response packet : your ISP won't route it on your line because the
destination address is not yours. Your ISP may even have dropped your
ourgoing packet because its source address is not the one that has been
assigned to your line, as a protection against spoofing.
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?
Here is what the pppd manpage states :
"When the demand option is used, the interface IP addresses have already
been set at the point when IPCP comes up. If pppd has not been able to
negotiate the same addresses that it used to configure the interface
(for example when the peer is an ISP that uses dynamic IP address
assignment), pppd has to change the interface IP addresses to the nego-
tiated addresses. This may disrupt existing connections, and the use
of demand dialling with peers that do dynamic IP address assignment is
not recommended."
In short : the dial-on-demand option won't work properly with a dynamic
IP address. I'm afraid the problem is inherent to the kernel networking
structure itself. A workaround could be to send another type of packet
before the TCP SYN, such as an ICMP ping or a UDP DNS request, if possible.
Reply to: