Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense in AWS as OpenVPN Client to OpenVPN server - Not working properly

    Scheduled Pinned Locked Moved OpenVPN
    3 Posts 2 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      paul.bargiel
      last edited by

      Hello Members,

      I am using 2.2.4 version of pfSense in AWS. I recently setup pfSense as an openvpn client to OpenVPN server.
      The tunnel is setup for peer to peer SSL/TLS. The tunnel comes up and i am getting the following results when pinging across the tunnel.

      1. Ping from the local LAN machine behind OpenVPN client(pfSense) to machine in LAN behind OpenVPN server works fine.
      2. Ping from machine behind OpenVPN server to machine in LAN behind OpenVPN client (pfSense) does not work. I did packet captures and tcpdumps and i can see the packet making it across the tunnel and reply is also being generated  but it does not go any further than pfSense LAN interface on the way back. It seems like the ping reply is not routed properly out the tunnel interface but instead dropped?. This happens only when ping is initiated from the machine behind OpenVPN server LAN. It works perfectly fine the other way around.

      Any help to resolve this will be appreciated
      Regards
      Paul Bargiel

      1 Reply Last reply Reply Quote 0
      • D
        divsys
        last edited by

        If the devices you're using for the pings are Win based, you might want to check the firewalls on both sides to make sure they're not blocking.
        That's a common head scratcher in OpenVPN setups.

        Have you checked "Firewall Rules->Open VPN" for an Allow Any-Any rule (allow all OpenVPN traffic) on both ends?

        -jfp

        1 Reply Last reply Reply Quote 0
        • P
          paul.bargiel
          last edited by

          First, thank you for your quick response.

          I use Linux (10.157.30.147) on one end which is on the LAN of pfSense Firewall and Windows (10.0.10.35) on the other end behind OpenVPN server. No firewall enabled on either of the boxes. I did tcpdump on pfSense and also on the Linux machine.
          On the Linux machine I receive the echo request and it also generates the echo reply. Please see below.

          [root@ip-10-157-30-147 ~]# tcpdump -i eth0 -p icmp
          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
          18:18:27.936003 IP 10.0.10.35 > 10.157.30.147: ICMP echo request, id 1, seq 2906, length 40
          18:18:27.936055 IP 10.157.30.147 > 10.0.10.35: ICMP echo reply, id 1, seq 2906, length 40
          18:18:32.928501 IP 10.0.10.35 > 10.157.30.147: ICMP echo request, id 1, seq 2907, length 40
          18:18:32.928553 IP 10.157.30.147 > 10.0.10.35: ICMP echo reply, id 1, seq 2907, length 40

          This means the ping (echo request) is traversing the tunnel and hits the Linux box, the Linux box responds as well. Let's take a look at pfSense now.

          The echo reply from Linux box is getting on the LAN interface of the pfSense firewall (xc1). Please see below output.

          [2.2.4-RELEASE][root@pfSense.localdomain]/root: tcpdump -i xn1 -p icmp
          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on xn1, link-type EN10MB (Ethernet), capture size 65535 bytes

          18:22:58.711404 IP 10.0.10.35 > 10.157.30.147: ICMP echo request, id 1, seq 2961, length 40
          18:22:58.711956 IP 10.157.30.147 > 10.0.10.35: ICMP echo reply, id 1, seq 2961, length 40
          18:23:03.719116 IP 10.0.10.35 > 10.157.30.147: ICMP echo request, id 1, seq 2962, length 40
          18:23:03.719689 IP 10.157.30.147 > 10.0.10.35: ICMP echo reply, id 1, seq 2962, length 40

          However, the traffic does not go over the Tunnel interface (ovpnc1) interface or WAN interface (xn0) after the LAN interface (xn1)i checked tcpdump on both while running continuous ping and nothing is showing up.

          To make it more complicated and proof that routing works properly, when I initiate the ping form the Linux box towards Windows. It works flawlessly
          I can also see tcpdump on the LAN and Tunnel interfaces of pfSense. Please check below.

          (pfSense - LAN interface)
          [2.2.4-RELEASE][root@pfSense.localdomain]/root: tcpdump -i xn1 -p icmp
          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on xn1, link-type EN10MB (Ethernet), capture size 65535 bytes
          18:33:56.021258 IP 10.157.30.147 > 10.0.10.35: ICMP echo request, id 10512, seq 22, length 64
          18:33:56.106887 IP 10.0.10.35 > 10.157.30.147: ICMP echo reply, id 10512, seq 22, length 64

          18:33:57.022572 IP 10.157.30.147 > 10.0.10.35: ICMP echo request, id 10512, seq 23, length 64
          18:33:57.108684 IP 10.0.10.35 > 10.157.30.147: ICMP echo reply, id 10512, seq 23, length 64

          (pfSense - Tunnel interface)
          [2.2.4-RELEASE][root@pfSense.localdomain]/root: tcpdump -i ovpnc1 -p icmp
          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on ovpnc1, link-type NULL (BSD loopback), capture size 65535 bytes

          18:36:47.092394 IP 10.157.30.147 > 10.0.10.35: ICMP echo request, id 14864, seq 4, length 64
          18:36:47.240297 IP 10.0.10.35 > 10.157.30.147: ICMP echo reply, id 14864, seq 4, length 64

          18:36:48.093977 IP 10.157.30.147 > 10.0.10.35: ICMP echo request, id 14864, seq 5, length 64
          18:36:48.261499 IP 10.0.10.35 > 10.157.30.147: ICMP echo reply, id 14864, seq 5, length 64

          All firewall rules for OpenVPN are any any.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.