Connection reset when using OpenVPN



  • I have troubles with uploading file to embedded device using port forwarding on OpenVPN-connected intermediate PC.

    The setup is as follows: PC connected to pfsense router, intermediate PC connected over OpenVPN to pfsense router and embedded device on the same LAN address space as intermediate PC. Embedded device listens on TCP port 6000.

    If I upload a file to embedded device directly from PC on the same LAN, there are no problems. See first Wireshark screenshot.

    alt text

    But if I upload it from the PC using port forwarding on intermediate, over OpenVPN connected PC with port-forwarding set up on it, the connection is reset after just a couple of packets. See second Wireshark screenshot.

    alt text

    The first obvious difference seems to be that the TCP packets in working example have flags [PSH, ACK], while the packets over OpenVPN+port forwarding just have [ACK] flag.

    The 54 Byte packets in Wireshark log are the "keep-alive" packets for connection to embedded device. All PCs are Windows 7.


  • LAYER 8 Global Moderator

    Where is the syn,ack coming back from the 10 box? Btw there is ZERO reason to hide rfc1918 address.

    I see a syn from 192.168 to 10 dest 6000 port, source 53176, then there sending ack, but you see no syn,ack answer from 10 to 53176

    So either your missing packets in this sniff - maybe you sorted it by source IP or dest IP?

    But PSH on an ack means nothing really.. That is NOT The reason of your problem..
    "PSH or PUSH flag is an option provided by TCP that allows the sending application to start sending the data even when the buffer is not full "

    Are you seeing RST? Which is how I read your thread title - if so, it might be your dest device doesn't want to talk to the remote IP.. It would be more helpful to see the sniff in time order.. I do see fin sent in in your second sniff and other connections happening with the SYNs



  • Here is full log at the time of event

    alt text

    alt text


  • LAYER 8 Global Moderator

    So those RST is 10.0.8.2 telling 192.168.1.10 to F off!! That has zero to do with pfsense.. Mabye it has a firewall and doesn't allow 192.168.1.10 to talk to it.

    You can see that 8.2 sends fin, then 1.10 sends its fin... But then continues to send traffic to same port 53163 so 8.2 sends RST.

    Not sure why you think this is a pfsense issue, clearly the devices are talking to each other..



  • Thanks for reply. Are you sure that it is 10.0.8.2 that rejects connection and not the final device to which 10.0.8.2 forwards the port 6000 to?

    Why do the first few packet pass through though?


  • LAYER 8 Global Moderator

    What? Dude you can not tell if your natting... Why would you be natting? rfc to rfc?



  • The 10.0.8.2 forwards port 6000 to a device on his own LAN, e.g. 192.168.14.17 (which is a primitive embedded device and can not use OpenVPN).

    So I connect from 192.168.1.10 to 10.0.8.2:6000 in order to access 192.168.14.17 which is on remote location.


  • LAYER 8 Global Moderator

    @mare said in Connection reset when using OpenVPN:

    (which is a primitive embedded device and can not use OpenVPN).

    So... What does that have to do with natting and port forwarding?

    If this 10.0.8.2 device is running openvpn.. You do not have to NAT you would route..


Log in to reply