port forwarding issue?

This is a real bummer. I caught it doing it just now, so I did a grep for dport=80 on the linode and saw:

tcp 6 114 SYN_SENT src=A.B.C.D dst=P.Q.R.S sport=32899 dport=80 packets=2 bytes=96 [UNREPLIED] src=10.8.0.2 dst=10.8.0.1 sport=80 dport=32899 packets=0 bytes=0 mark=0 secmark=0 use=1

I don't have it in my cut&paste buffer, but on the real server (at the other end of the openvpn tunnel), the matching entry showed up as FIN_WAIT.

Update: I was running a script that connects on port 80 and then disconnects. I tried running two at the same time, and when the freeze happened, both processes were stuck, and doing cat on the conntrack pseudofile, showed two entries in SYN_SENT state. I'm mystified as to why one entry can get stuck, but even more mystified as to why this would prevent any new connections on that port.

@dswartz:

I used DNAT to push packets arriving on eth0 into tun0,
How did you do that ? I've tried to set up OpenVPN on a server with apache. I want to connect using OpenVPN and then see the webserver.

I think I need to take incoming tun0 packets at route to lo, but I can't work out how to do this. IPTABLES appears to route packets but when I check the apache access_log it still shows incoming IP address as the remote client not as from the local machine.

So what you did above, sounds similar to what I need to do.

````
/sbin/iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.8.0.2
/sbin/iptables -t nat -I POSTROUTING -o tun0 -p tcp --dport 80 -j SNAT --to-source 10.8.0.1

````

@dswartz:

Update: I was running a script that connects on port 80 and then disconnects. I tried running two at the same time, and when the freeze happened, both processes were stuck, and doing cat on the conntrack pseudofile, showed two entries in SYN_SENT state. I'm mystified as to why one entry can get stuck, but even more mystified as to why this would prevent any new connections on that port.

I don't suppose you've hard-coded the source port (32899?) in your script? Or that something else is causing the same source port to be reused? Because that would explain your symptoms. TCP identifies connections based on the source/destination address/port quadruple, and it doesn't like duplicates.

No, it's just a simple DNAT iptables command. And the failure would happen after doing N connects in a row from the remote host. No idea what the problem was…