@gunnyp

Self-inflicted!
Forgot to change the IP address of the managed switch that sits between the servers and the pfSense vm.
IVPN is up and running.

Good news. I've managed to figure out my major bottleneck. My main Win10 machine at home has a stu*** Intel I225-V 2.5 Gbit on board ethernet NIC that I was using. It has caused weird issues in the past with random disconnects and is globally known for its issues.. I have plugged in a ASUS USB 2.5 Gbit adapter and sure enough I am able to max out my wire speed now using the wireguard tunnel.

OpenVPN also works equally well now as on the other machine, and I figured out that enabling DCO in the OpenVPN client side can bring me close to peak speeds of 400Mbit wire speed. I haven't enabled DCO on the OpenVPN server side yet. I am still using OpenVPN via TCP, and I read for DCO thats not supported/recommended - even though interestingly enough it already gives me a performance boost already now just enabling it on the client side. Switching OpenVPN server to using UDP and enabling DCO on the server side as well might further improve things I imagine - something I might try in the next days.

Hope this thread will help somebody down the road troubleshooting the same.

@ahking19 Thanks for your reply. Both machines are on wired ethernet on the same router at home. I think I am not near maxing out the Netgate CPU, but I've attached a screenshot below to be sure (not sure how to interpret that plot exactly):
e7b8a2a8-aea9-4b8a-a82e-09a91455386a-image.png

Latency wise: I have about 9-15 ms ping through the OpenVPN tunnel from client to my netgate.
Using wireguard is about 9-11ms.

@compsmith said in Road Warrior need access all spokes in hub/spoke multisite:

Anyone out there have any insight to get this to work?

[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 :)

How is this still not a feature???
This should be the feature to be included in year 2024!!

I want this feature so bad that I might visit forum once a week to keep this post on the top page...

@Jarhead I do it like that. It might be less secure, but how much?
I wish we could get rid of the Resolver ACL too. 😁

@Jarhead said in Why use Allowed IP's?:

why would we ever set specific Allowed IP's if they really aren't doing anything needed? (like creating routes for example)

If you have more than one other peer, you can do 0.0.0.0/0 only on one.

@jhl

Yes, the older version of iperf3 on Windows clients was to blame for low testing speeds.

@marksmeets The allowed IP's are the networks on the other side of the tunnel that will be allowed to traverse the tunnel.
On the peer config in pfSense, not the actual peer, you're only allowing the tunnel IP. You should also add 0.0.0.0/0 as allowed.
My thinking was this was causing the problem when the AP changed since you said the laptop would then have a different IP.

@n3IVI0 My setup was correct. The problem was on Mullvad's end. The first server in my list was one of their Houston servers. It's a fast server, one I tend to use a lot. And it was first in line. That server appears to be down. None of my clients will connect to it. The moment I tried to connect to a different one, it connected immediately.

And yes, I should have thought of that. I am working through some jet lag at the moment. DOH.

Been running in circles for days trying to figure this out.

@JustAnotherUser I guess I'll say it again, you would have to allow computer 2 across the WG0 tunnel.

@JustAnotherUser
did you save your config before trying to add the wireguard VPN? If so load the old config and reboot your system to get back to a known working router with OpenVPN.

Try again next week.

I run both wireguard and openvpn servers and clients simultaneously.

@Tenorbro It does not need to be assigned but that changes the rules. You would then not have a discreet interface to put rules on and only use the Wireguard group for rules. This could be problematic if you have a few tunnels so it's easier to assign an interface just because of the rules.
This also depends on the WG setting "Interface Group Membership".

@java4dev You also need routes and the correct config of Wireguard at Site HQ.
If you don't figure it out, post a lot of screenshots I guess.