Messages

I got to the point here where I thought it would be a good idea to test the pfSense tutorial on pfSense itself to see if that even worked for me with the same setup.  (Unfortunately?) It did.


I followed the instructions and went right through the tutorial without any issues. pfSense is working correctly and I'm finding that VPN speeds are working as advertised with greatly enhanced performance that exceed the ISP limitations. It's very impressive actually, but I really wish I could have figured out what the differential is between the tutorial DNS section working fine with pfSense and not working with OPNsense.


Is there anything that can be done with this information? Can the configuration file be reviewed somehow to see what's being missed and migrated to OPNsense?

I had some things come up and haven't had much time to work on this, but I've managed to find some time to come back to this issue today.  I thought I'd do some testing at each step in the process and unfortunately while I think I have a better picture of what's going on, I'm even more confused now.


First, one thing that has confused me is that I've managed to get the VPN working, but while IPv4 shows the right remote IP address, IPv6 appears to be skipping over the VPN and just using the local ISP/WAN interface and I can never get it to go through the VPN. I figured maybe I need to block it and I can't even figure out how to do that so just IPv4 is only used in case that's an issue (but I don't think it is since, I THINK, PIA has used IPv6 before).


So now I have things arranged a little differently. I have OPNsense as the primary gateway now for my network.


I have one test system assigned to the VPN_Recipients alias which means I can keep tests isolated for it.  Everything else is just on the LAN and my goal is to make them all just behave normally and pass through the WAN port only without touching the VPN.


For some details:

   
• 192.168.0.211 is the only IP within VPN_Recipients
• The VPN client is "PIA East" (screenshot)
• Unbound is on and listening at 53 (screenshot)
• I have 3 Interfaces: LAN, PIAEast, and WAN.
• Outbound NAT (Overview, Details)
• Firewall Rules (Overview)

Notice I put the first two rules under the Anti-Lockout Rule in order to pass all traffic from the LAN that's NOT within the VPN_Recipients list on out to the default WAN. I wanted to keep my network working while doing the configuration work and seems sane to do something like this.


So I've found a couple of things particularly strange and I'm hoping you can elucidate the issues. I really was hoping that I could do an nslookup in all cases, but here's what I'm seeing:


When I have the VPN turned OFF, I can, from regular LAN systems, ping anything fine and "nslookup google.com 192.168.0.1" works great. Same is true of 192.168.0.211.


When I turn on the VPN, I cannot ping anything, but I CAN run "nslookup google.com 192.168.0.1" fine. From 192.168.0.211 I CANNOT run nslookup (times out), and I cannot ping a domain (like google.com), but I CAN ping 8.8.8.8.


Leaving VPN on, if I change the "NON-VPN - Default allow LAN to any rule" rule so that Gateway is NOT "default" but  is instead set to "WAN_DHCP", I can then ping 8.8.8, but nslookup and name resolution still won't work.


I'm just not really seeing exactly what's going on here. Why would DNS resolution work and it seems that at other times when I was playing here with the settings I got DNS resolution for OPNsense to work while the VPN was on, but I lost track of the settings that did this. I'm obviously not understanding a crucial part of the puzzle.

Ah, lol, got it. Crazy me. I unthinkingly set the subnet to 192.168.0 instead of .1 this time around just powering through things. Thanks for the sanity catch there!!!! So nslookup DOES work now, that's really good!

So I've mixed this up a little bit. I thought I'd try to test a few things. I've gone ahead and put OPNsense right on the head of my network with no other possible traffic at this point. I'm using a vanilla setup with really no customization. I thought I'd see if I could at least get Unbound responding to local traffic FIRST before setting up anything else whatsoever.


I'm able to talk to the internet just fine, no additional firewall rules, nothin' at all. Unbound is supposedly on:



But when I even test this I get a timeout:

Code Select Expand



nslookup google.com 192.168.1.1
;; connection timed out; no servers could be reached



Now that has me really scratching my head! Any thoughts on this?

Oh that's really good. Thank you. It seems it would make sense if someone were to make a config that works with PIA for example with as generic as possible options (DHCP everywhere), maybe that would help other people out instead of having to go through so many steps. I'll give this a shot here and see how it works.

I'm curious about a test here. Is there a way to save the configuration of OPNsense so that I can load it up on a physical machine attached to my network to see if this is still happening? I've got some extra systems sitting around I could load up OPNsense onto and then see where that goes...

I'm using Proxmox with an OVS Bridge. So I have The ISP traffic coming in to a Windows 2012 Server that shares this connection out from 192.168.137.1 to a virtual switch (we'll call vswitch1).  This virtual switch is also set up as the WAN port for OPNsense (192.168.137.95). I then have a second virtual switch (we'll call vswitch2) providing LAN connections for the Windows and Linux machines I've been doing the testing on.


I do have another Linux server on vswitch1 (wan 192.168.137.250) that provides Internet access to the rest of my network.


Clearly the Windows 2012 gateway is just temporary. I was using it to test some various scenarios for PIA connectivity that just didn't work out well. My goal is to replace it with OPNsense, but I'd like to actually get OPNsense working properly before I swap it out since we have actual time sensitive work to do and can't afford the downtime right now...  :'(

It is a little strange. I do see a lot of PIA East traffic on WAN, which is right since that connection is connecting to that.


I do also see some other odd traffic (?) like this NTP traffic:



I guess this confuses me since I still have 192.168.1.20 on the VPN_Recipients alias list. I tested and I still can't get any name resolution:


I then noticed a bunch of other UDP traffic from firefox pour across from .20 (I did have it open, but wasn't resolving):


I will say that while I was watching it I found that a lot of the traffic (nearly all of it after I closed down Firefox and disabled NTP on the Linux machine), was PIA VPN traffic on UDP. I checked this by reverse greping the PIA IP that was being used so that I was only seeing traffic (except for the time/informational header info) for non PIA bound or source traffic.

@chemlud as you asked (I think @Animosity022 looked at previous the posting for this info and @Animosity022 I have your answers below):





So @Animosity022 I have 192.168.137.1 as the WAN in this case since it's a test. My ISP only allows 1 IP lease and so I have a router pushing traffic to OPNsense until I can get it functional and replace it with OPNsense. So for now I have: ISP (Public IP) --> Router (192.168.137.1) --> OPNsense (192.168.1.1)


This Router is NOT offering DHCP, it's just static so I configured OPNsense statically (screenshot of WAN config).


Routes->Configuration: No, "No results found!"


LAN config:

Summaries:



Did you also want the detailed views?

Summary:



Details:

So first, I've taken 192.168.1.20 and put it in the alias list to receive the VPN and got the same results:









Windows then behaves just like the Linux computer when it is removed from the VPN_Recipients alias list:

Yes, so as I mentioned earlier, I do have 192.168.1.20 which is a Linux system. I made sure that it was not in my "VPN_Recipients" list and I then tried a couple things that both worked. Here's what I did in Linux:


Here's the firewall live log output:

OK yes, I see what you're saying since random ports are used from the client to connect to the server's 53. But :( sadly I still get a timeout: