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

    NAT works incorrectly with several OpenVPN clients

    Scheduled Pinned Locked Moved NAT
    3 Posts 2 Posters 511 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.
    • D
      dims
      last edited by

      I have created two OpenVPN client connection and they work, i.e. I can ping VPN machines from pfSense box.

      VPN machine behind one connection is 10.10.0.251 and 10.30.0.252 is behind the other.

      Ufortunately, I can't ping VPN machines from my LAN.

      I got tcpdump running and monitoring LAN and OpenVPN interfaces on pfSense box.

      When I ping 10.10.0.251 from pfSense box itself, I see both requests and responses, which means target machine works.

      When I ping 10.10.0.251 from my LAN machine, I see ICMP requests both on LAN and OpenVPN interfaces of pfSense. This means that routing works.

      But I don't see any ICMP responses.

      I suggested, that target machine is configured not to answer on packets from foreign networks. So, I decided to configure NAT so that all packets come as if being sent from pfSense box.

      First I have configured these two rules:

      I found, that NAT works incorrectly and unpredicatble. Below is tcpdump:

      18:51:57.192650 IP 10.11.0.34 > 10.10.0.251: ICMP echo request, id 28597, seq 0, length 64
      18:51:57.387394 IP 10.10.0.251 > 10.11.0.34: ICMP echo reply, id 28597, seq 0, length 64
      18:51:58.224948 IP 10.11.0.34 > 10.10.0.251: ICMP echo request, id 28597, seq 1, length 64
      18:51:58.419498 IP 10.10.0.251 > 10.11.0.34: ICMP echo reply, id 28597, seq 1, length 64
      18:51:59.225945 IP 10.11.0.34 > 10.10.0.251: ICMP echo request, id 28597, seq 2, length 64
      18:51:59.421296 IP 10.10.0.251 > 10.11.0.34: ICMP echo reply, id 28597, seq 2, length 64
      18:52:00.226942 IP 10.11.0.34 > 10.10.0.251: ICMP echo request, id 28597, seq 3, length 64
      18:52:00.421685 IP 10.10.0.251 > 10.11.0.34: ICMP echo reply, id 28597, seq 3, length 64
      18:52:01.227946 IP 10.11.0.34 > 10.10.0.251: ICMP echo request, id 28597, seq 4, length 64
      18:52:01.422558 IP 10.10.0.251 > 10.11.0.34: ICMP echo reply, id 28597, seq 4, length 64
      18:52:40.534442 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 64810, seq 174, length 40
      18:52:45.288729 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 64810, seq 175, length 40
      18:52:50.288846 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 64810, seq 176, length 40
      18:52:55.288659 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 64810, seq 177, length 40
      18:54:25.845990 IP 10.11.0.0 > 10.10.0.251: ICMP echo request, id 47452, seq 178, length 40
      18:54:30.786771 IP 10.11.0.0 > 10.10.0.251: ICMP echo request, id 47452, seq 179, length 40
      18:54:35.786875 IP 10.11.0.0 > 10.10.0.251: ICMP echo request, id 47452, seq 180, length 40
      18:54:40.787053 IP 10.11.0.0 > 10.10.0.251: ICMP echo request, id 47452, seq 181, length 40
      19:02:34.806663 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 61799, seq 182, length 40
      19:02:39.778523 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 61799, seq 183, length 40
      19:02:44.778068 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 61799, seq 184, length 40
      19:02:49.778073 IP 10.12.0.23 > 10.10.0.251: ICMP echo request, id 61799, seq 185, length 40
      19:03:43.232344 IP 10.169.10.1 > 10.10.0.251: ICMP echo request, id 17228, seq 190, length 40
      19:03:47.776844 IP 10.169.10.1 > 10.10.0.251: ICMP echo request, id 17228, seq 191, length 40
      19:03:52.777013 IP 10.169.10.1 > 10.10.0.251: ICMP echo request, id 17228, seq 192, length 40
      19:03:57.776056 IP 10.169.10.1 > 10.10.0.251: ICMP echo request, id 17228, seq 193, length 40
      19:04:23.430011 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 194, length 40
      19:04:28.276488 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 195, length 40
      19:04:33.275572 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 196, length 40
      19:04:38.276237 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 197, length 40
      19:04:47.121862 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 198, length 40
      19:04:51.776824 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 199, length 40
      19:04:56.777018 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 200, length 40
      19:05:01.775425 IP 10.170.10.1 > 10.10.0.251: ICMP echo request, id 21649, seq 201, length 40
      
      

      All pings were issued towards the same IP. First rows are for pings from pfSense box itself. Other rows are for same ping from LAN machine

      ping 10.10.0.251

      as you see, source address is somehow random althoug it appears in correct subnet.

      I have also tried to play with translation config option, but still failing.

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        All right here. You have no NAT rule for any of these source addresses.
        There's only a NAT rule for the source 192.168.10.0/24.

        So if you want NAT to work for other sources add a rule for it or change the source in the existing rule to any.

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

          If NAT is not working, then who replaced source addres from 192.168.10.56 to something else?

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