I> I'm starting to feel like I *almost* understand what's happening here. I'm I> actually in the middle of making some changes to natd, but not to this part I> of it. (I'm just fixing some bugs in the code that translates IRC DCC I> control message packets.)
I> From the output you posted, things start out looking normal. Your IP on I> this PPP session appears to be 207.69.102.20: >> >> Out [TCP] [TCP] 192.168.0.10:3978 -> 207.69.200.225:110 aliased to >> [TCP] 207.69.102.20:3978 -> 207.69.200.225:110 >> In [TCP] [TCP] 207.69.200.225:110 -> 207.69.102.20:3978 aliased to >> [TCP] 207.69.200.225:110 -> 192.168.0.10:3978 >> Out [TCP] [TCP] 192.168.0.10:3978 -> 207.69.200.225:110 aliased to >> [TCP] 207.69.102.20:3978 -> 207.69.200.225:110 >> In [TCP] [TCP] 207.69.200.225:110 -> 207.69.102.20:3978 aliased to >> [TCP] 207.69.200.225:110 -> 192.168.0.10:3978 >> >> Above is where I think the end of one ppp session is. My workstation >> is finishing talking with the mail server. >> I think the next ppp session is dialed here somewhere. >> >> Routing message 0x2 received. >> Routing message 0xd received. I> As I understand it, you have no PPP IP at this point, that's what the 0x2 I> and 0xd routing messages were telling natd: a route and an address were I> removed from the interface. But natd ignores this condition (other than I> logging that it got the notification on the routing socket). Now it gets I> some outgoing packets from the workstation, and translates them using the I> old IP address: >> Out [TCP] [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to >> [TCP] 207.69.102.20:3979 -> 207.69.200.225:110 >> Out [TCP] [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to >> [TCP] 207.69.102.20:3979 -> 207.69.200.225:110 >> Out [TCP] [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to >> [TCP] 207.69.102.20:3979 -> 207.69.200.225:110 I> Where did these packets go? I can't answer that. However I can speculate I> that perhaps they didn't go very far at all, just into the IP stack on the I> local machine. Then we get some more routing info: >> Routing message 0x2 received. >> Routing message 0xd received. >> Routing message 0xc received. >> Interface address/MTU has probably changed. >> Routing message 0x1 received. >> Routing message 0xc received. >> Interface address/MTU has probably changed. >> Routing message 0x1 received. >> Routing message 0x1 received. >> Routing message 0x3 received. >> >> I see that the IP changed above and natd recognized that Here is where >> natd enters the cone of confusion. It starts relaying messages from >> the mail server to its previous IP. I> It's the 0xc messages that cause natd to notice it has a new address on the I> dynamic interface. This causes it to discard existing stale alias entries I> in its internal tables and obtain the new IP from the interface (actually it I> just sets a flag to get the new address the next time a packet comes I> through). I think the new IP at this point is 207.69.100.116. I> Now we get the really confusing part: >> In [TCP] [TCP] 207.69.200.225:110 -> 207.69.102.20:3979 aliased to >> [TCP] 207.69.200.225:110 -> 207.69.102.20:3979 >> Out [TCP] [TCP] 207.69.200.225:110 -> 207.69.102.20:3979 aliased to >>>>>>>>>> [TCP] 207.69.100.116:110 -> 207.69.102.20:3979 I> I think the "In" packet here may be the last "Out" packet from above. It I> floated around in the IP stack and since IP forwarding is on it decided the I> packet needs to be routed out the default gateway to get where it's going I> (because 207.69.102.20 isn't us anymore). Or maybe something else is going I> on here, but it's hard to explain how a packet for 207.69.102.20 ended up on I> the input side since that isn't our IP anymore. I> Then, the "Out" packet here is the attempt to route that same packet back I> out the default gateway. This time, on the way out, the packet is aliased I> so that the source address is the new IP for the PPP interface. I> I think the bulk of the problem happens when outbound packets appear during I> the brief time when the PPP interface has no IP yet (at least from natd's I> point of view, because it received the DELADDR routing message but hasn't I> gotten the NEWADDR message yet). I think when natd gets the DELADDR it I> should clean up its aliasing tables at that point, and forget any old IP I> addresses for that interface. But then what does it do about packets that I> come through while it's in that state? I'm not sure what the right answer I> is, maybe one of the people who maintains this part of natd would have a I> better answer. I> -- Ian I think you are right, Ian. after I sent the last post, and thought more about it, I think I almost understand it also. You guys correct me if I am wrong somewhere, please. 1. The link is down. Natd has no way of knowing what the next IP will be. So, it keeps the previous IP in its database. 2. I send natd something outgoing. Since the link is not up yet, and the IP is not known yet, natd translates the packet with using a previous public IP and gives it to ppp. 3. Ppp sets up a link, and sends the packets given to it by natd with a previous sessions source IP. It seems that at this point the machine is actually spoofing some packets using an address that may have already been reassigned by Earthlink dial-up servers to another dial-up machine. 4. Worse than that, the receiving server accepts the invalid source address as valid, and replies to me, even though I now have a different valid source IP. I think arp is somehow involved here. 5. While that whole spoofing transaction is going on on the Internet, natd on my machine realizes that it now has a different IP, and updates its database. 6. When the replies from the spoofed packets return to natd, what Ian said happens. Natd realizes that the destination IP is not local, and tries to route the packet back out to the proper destination IP. I have it set to keep ports the same if possible. So, if the packet came from a DNS server, natd uses source port 53 to route the packet back out. 7. Of course, these nonsense packets run into the firewall rules, as they should. That's where I see the error messages from natd. I think I have 2 things to work out here: 1. Stop ppp from sending out spoof packets on initial link setup. 2. Stop replies to those packets from getting to natd. Perhaps, if I can do the first, the second won't be necessary. I am working on setting up ppp filters just for that using MYADDR variable. Does that sound like the best way to do it? Thank you very much, Ian. I think this is almost solved. Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
