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

    Using WG to encrypt WiFi clients?

    Scheduled Pinned Locked Moved WireGuard
    2 Posts 1 Posters 226 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.
    • N
      NerdyVeteran
      last edited by NerdyVeteran

      I'm trying to create a tunnel for a wifi client to send all traffic over between themselves and the WLAN interface on pfSense.

      General Flow:
      Client --))) [ wg_tun0 ] (((-- em2:WLAN <--> em0:WAN <--> Internet

      Steps I've followed so far:
      On pfSense:
      1.) Create wg_tun0 (10.100.0.100/31)
      2.) Create peer (10.100.0.101/31)
      2a.) Dynamic Endpoint selected
      2b.) Allowed IPs: 10.100.0.101/32
      3.) Firewall/Rules/Wireguard, Pass any -> any
      4.) Firewall/Rules/WLAN, Pass udp any -> any:51820

      Client:

      [Interface]
PrivateKey=Shhhh.........
Address=10.100.0.101/31
DNS=<WLAN_address>
[Peer]
AllowedIPs=0.0.0.0/0
Endpoint=<WLAN_address>:51820

      Tunnel comes up just fine. However, I can't route anywhere beyond pfSense. I'm not even sure the traffic is being sent over the tunnel. I assume I need to insert a route somewhere. What am I missing and where? Note: If it's not obvious, I want this to be a full tunnel.

      Thanx

      N 1 Reply Last reply Reply Quote 0
      • N
        NerdyVeteran @NerdyVeteran
        last edited by

        [Troubleshooting/Fix]

        Pinging from Client -> Youtube.com (142.250.180.14).

        PCAP on em0:WAN

        #Tunnel Disabled:
18:48:21.808185 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 990, offset 0, flags [none], proto ICMP (1), length 84)
    WAN_address > 142.250.180.14: ICMP echo request, id 61165, seq 7, length 64
18:48:22.516482 xx:xx:xx:xx:28:27 > xx:xx:xx:xx:66:8a, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 110, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    142.250.180.14 > WAN_address: ICMP echo reply, id 61165, seq 7, length 64
18:48:22.817329 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 63388, offset 0, flags [none], proto ICMP (1), length 84)
    WAN_address > 142.250.180.14: ICMP echo request, id 61165, seq 8, length 64
18:48:23.518344 xx:xx:xx:xx:28:27 > xx:xx:xx:xx:66:8a, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 110, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    142.250.180.14 > WAN_address: ICMP echo reply, id 61165, seq 8, length 64
18:48:23.822630 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 5156, offset 0, flags [none], proto ICMP (1), length 84)
    WAN_address > 142.250.180.14: ICMP echo request, id 61165, seq 9, length 64
18:48:24.526677 xx:xx:xx:xx:28:27 > xx:xx:xx:xx:66:8a, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 110, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    142.250.180.14 > WAN_address: ICMP echo reply, id 61165, seq 9, length 64
#Tunnel Enabled:
18:48:24.824198 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 30834, offset 0, flags [none], proto ICMP (1), length 84)
    10.100.0.101 > 142.250.180.14: ICMP echo request, id 30738, seq 10, length 64
18:48:25.833285 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 23547, offset 0, flags [none], proto ICMP (1), length 84)
    10.100.0.101 > 142.250.180.14: ICMP echo request, id 30738, seq 11, length 64
18:48:26.834520 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 64833, offset 0, flags [none], proto ICMP (1), length 84)
    10.100.0.101 > 142.250.180.14: ICMP echo request, id 30738, seq 12, length 64
18:48:27.840448 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 50822, offset 0, flags [none], proto ICMP (1), length 84)
    10.100.0.101 > 142.250.180.14: ICMP echo request, id 30738, seq 13, length 64
18:48:28.843054 xx:xx:xx:xx:66:8a > xx:xx:xx:xx:28:27, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 62192, offset 0, flags [none], proto ICMP (1), length 84)
    10.100.0.101 > 142.250.180.14: ICMP echo request, id 30738, seq 14, length 64

        So it appears there's no NAT for the 10.100.0.100/31 traffic. I tried creating the Hybrid NAT rule below:

        Interface: Wireguard
Source: Wireguard networks
Source Port: any
Static Port: unchecked
Destination: any
Destination Port: any
NAT Address: WAN_address

        However I was still seeing traffic not being NAT'ed. So I tried adjusting it:

        Interface: WAN
Source: Wireguard networks
Source Port: any
Static Port: unchecked
Destination: any
Destination Port: any
NAT Address: WAN_address

        Alas, this STILL did not work. On a hunch, I tried using the subnet specifically instead of "Wireguard networks" and suddenly it worked:

        Interface: WAN
Source: 10.100.0.100/31
Source Port: any
Static Port: unchecked
Destination: any
Destination Port: any
NAT Address: WAN_address

        Is this behavior desired? It seems incongruent with the rest of the UI. The alias "Wireguard networks" does not appear to include the peer network. It seems like a rather simple addition to the Wireguard package.

        Now I have encrypted traffic that cannot be easily cracked over the air :)

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