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

    NAT WG clients throught IPSec site-to-site

    Scheduled Pinned Locked Moved
    IPsec
    1
    1
    140
    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.
    • A
      argonlam
      last edited by

      I am trying to make use of pfSense as a VPN server at home using PVE. The pfSense server only has 1 NIC and is running at the same network in site 1.
      I have already setup a IPSec site-to-site VPN
      access 192.168.203.0/24 INTERNET access 192.168.202.0/24
      192.168.202.0/24 <-----------------------------> 192.168.202.2 <~~~~~~~> 192.168.203.2 <----------------------------> 192.168.203.0/24
      Site 1 pfSense VPN server Linux Strongswan site 2

      • All traffics from WAN NET is allowed to access site 2 network
      • WAN address is allowed to access site 2 network (It should be duplicated)
        It works well and all clients in site 1 can access any servers in site 2 without any problem.
        *** The IKEv2 pharse 2 tunnel is NOT allowed to changed. Site 2 only accept clients access from 192.168.202.0/24 networks

      Then I setup a Wireguard VPN server (172.22.202.2/24) for roaming clients. Firewalls are set as follows:

      • All WG clients can access all (0.0.0.0/0)
      • A NAT rule is set to nat all WG clients to WAN address (192.168.202.2)
        It works as expected. WG clients access site 1 using WAN address by checking server logs in site 1.

      Here comes the problem. WG clients are unable to access any servers in site 2.

      I carried the following test case:
      Assumption:
      WG client: 172.22.202.103
      SSH Server in site 2: 192.168.203.2

      I checked with Packet Capture from pfSense on tun_wg0. It captured packets from WG client to SSH server.
      17:59:33.344469 IP 10.133.202.103.50456 > 192.168.203.2.22: tcp 0
      17:59:34.374829 IP 10.133.202.103.50456 > 192.168.203.2.22: tcp 0
      17:59:36.384212 IP 10.133.202.103.50456 > 192.168.203.2.22: tcp 0
      17:59:40.454297 IP 10.133.202.103.50456 > 192.168.203.2.22: tcp 0

      Then I checked again on vtnet0 (WAN), it showed related entries:
      18:01:07.183200 IP 192.168.202.2.36505 > 192.168.203.2.22: tcp 0
      18:01:07.183614 IP 192.168.202.2.36505 > 192.168.203.2.22: tcp 0
      18:01:08.185028 IP 192.168.202.2.36505 > 192.168.203.2.22: tcp 0
      18:01:08.185427 IP 192.168.202.2.36505 > 192.168.203.2.22: tcp 0

      It looks like 172.22.202.103 was translated to 192.168.202.2 already.

      Then I checked again with enc0 (IPSec), it showed related entries:
      18:04:19.911403 (authentic,confidential): SPI 0xc1e46fea: IP 192.168.202.2.52296 > 192.168.203.2.22: tcp 0
      18:04:20.269368 (authentic,confidential): SPI 0xc1e46fea: IP 192.168.202.2.18488 > 192.168.203.2.22: tcp 0
      18:04:20.496886 (authentic,confidential): SPI 0xc1e46fea: IP 192.168.202.2.52296 > 192.168.203.2.22: tcp 0

      I suppose it should works as it's going to the SPI table already.
      However, I capture nothing on the peer side (192.168.202.2) using tcpdump.
      Traffics from all clients in site 1 can be captured.
      I also tried to use the SHELL in pfSense to ssh to the peer side and it works, which means 192.168.202.2 is allowed to access 192.168.203.2.

      I tried the same setup using Linux (strongswan + Wireguard) and it works well.
      I tried many firewall rules and NAT and still unable to achieve my purpose.

      Hope any expert can help on my situation. Thanks in advance!

      1 Reply Last reply Reply Quote 0
      • First post
        Last post