Ian wrote: > > 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 > > Where did these packets go? I can't answer that. However I can speculate > that perhaps they didn't go very far at all, just into the IP stack on the > local machine. Then we get some more routing info:
FWIW: I've seen something similar with an IPSEC based VPN; it's my opinion that the problems are related, and that this is a routing issue, not a NAT issue. In the IPSEC case, if there is an explicit point-to-point route, and the default route is *NOT* set, then you get packets. If the default route is used to deliver the packets to the tunnel, then the packets get to the remote end, but the reply packets to the local end, which show up in tcpdump as hitting the local wire, don't make it up the stack for some reason. There appears to be a problem with the route cloning code not noticing correctly when a new route is established that applies to an already cloned connection, I think. This normally isn't a problem, but in the IPSEC or NAT case, wheere you are on a network border with another network in the same box, and you effectively need to have the moral equivalent of two different default routes, it seems to become an issue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message