> It's easier than that: from your peer, ping the ptp address (the CIPE
> address) and then on your local system, do a tcpdump -i eth0 udp port xxxx
> You should see the encrypted packets arriving.
Linux A--------NAT/Firewall---| Internet |-----------Linux B
Pretty interesting... I did this. Basically when I tried to ping Linux A
Linux B, nothing showed up on tcpdump. Then I tried pinging Linux B from
A. All of sudden tcpdump showed lots of activity. I can even stop the ping
coming from Linux B and the ping from Linux A continues fine (activity showing
up in tcpdump). If I stop the ping from Linux B to Linux A and wait 10
I can no longer ping from Linux B to Linux A.
Obviously the NAT box is doing something to the packets. Now a couple more
1) Someone e-mailed me and suggested that the NAT box is mangling the source
port. That is Linux B is sending from port xxxx but the NAT box mangles this
yyyy. In the config for Linux A I say that Linux B sends from port xxxx.
CIPE check and see that the source port doesn't match the config?
2) For some reason when I initiate the connection from Linux A, the port seems
to "open up" until Linux A stops sending. The window seems to close after 10
seconds. I could understand this if UDP was connection-oriented, but since it
isn't, I dont' see why the NAT box tears down the connection. Can anyone
explain the config that is being used that would do this with a UDP
I just wish that I could put my machine out on the Net and let iptables do its
job and not some broken NAT box <sigh>