Messages

Thank you both for your thoughts. Upon further testing, I now suspect that it has something to do with the external internet connection. I had only tested it by tethering my phone to access the VPN from the outside and that connection had a pretty high latency. Yesterday, I had the chance to test it from an external decent wifi with much lower latency and I was actually able to access the Web GUI when connected to the VPN with that more reliable internet connection. So maybe it's not a problem with OPNsense after all.

I'm baffled by this issue that I'm seeing.

I set up a Wireguard VPN and I can connect my client without issues both when I'm on my internal WiFi (which doesn't have direct access to the Web GUI) and when I'm totally outside my home network (i.e. coming from the internet).

Regardless how I connect to the VPN (from inside or outside), I can ping OPNsense (192.168.1.1) as well as other LAN hosts and I can SSH to both OPNsense and LAN hosts (which would not be allowed if I was on my WiFi without VPN). So far so good. When I'm connected to the VPN from the INSIDE wifi, I can also access the Web GUI at https://192.168.1.1. However, when I'm connected to the same VPN from the OUTSIDE (internet), I cannot access https://192.168.1.1. Even though I can ping and ssh to 192.168.1.1 just fine. Using telnet 192.168.1.1 443 I can connect to OPNsense on port 443, but when I try curl https://192.168.1.1, I get this output:

*   Trying 192.168.1.1:443...
* Connected to 192.168.1.1 (192.168.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

And it just hangs there. Incidentally, connecting via HTTP works and I get the redirect:

*   Trying 192.168.1.1:80...
* Connected to 192.168.1.1 (192.168.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.1.1
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Location: https://192.168.1.1/
< Content-Length: 0
< Date: Wed, 03 Mar 2021 18:07:31 GMT
< Server: OPNsense
<
* Connection #0 to host 192.168.1.1 left intact

By the way, I've also tried it with OpenVPN instead of Wireguard and the same thing happens. When I connect from the outside, I can ping and ssh 192.168.1.1 but the TLS handshake hangs.

Does anybody have any idea what's going on here? How would the OPNsense webserver even know whether I'm connecting to the VPN from outside or inside? It should loke the same for it, shouldn't it? My VPN tunnel IP is the same in both cases.

Any help would be greatly appreciated!

I need to correct myself: nping does NOT work (I didn't carefully look at the output). So is it possible that the firewall blocks the returning ping packages?

I just recently switch from pfSense to OPNsense and I'm having some issues with accessing clients connected to a different interface. Here's the situation (this is simplified):

LAN: subnet 192.168.1.0/24, DHCP provided by OPNsense
OPT2: subnet 192.168.150.0/24, DHCP provided by OPNsense (address pool 192.168.150.200 - 192.168.150.254)

I have a simple WiFi access point connected via ethernet to OPT2. Unfortunately, it does not have a DHCP client, so I have to manually set its IP to 192.168.150.100. The WiFi works and WiFi clients get an IP from OPNsense in the range 192.168.150.200 - 192.168.150.254.

I can ping WiFi clients from LAN (for example, I can ping 192.168.150.200 from LAN), but I cannot ping the access point itself (with the manually configured IP) from LAN, i.e. I cannot ping 192.168.150.100 from LAN (I can, however, ping it from the OPT2 interface of OPNsense, so OPNsense can ping 192.168.150.100 from 192.168.150.1 but not from 192.168.1.1).

So basically that means I cannot configure the AP from any computer in my LAN.

Is this expected behavior or did I mess something up? I was playing with setting a manual gateway (192.168.150.1) and then manual route using that gateway to 192.168.150.100, but I ended up getting an infinite loop (traceroute just got stuck on 192.168.150.1).

One last note: sudo nping --icmp --dest-mac <MAC of OPNsense OPT2 interface> 192.168.150.100 DOES work. So that leads me to believe that this is a routing issue and not a firewall issue (obviously, I'm not passing traffic from OPT2 to LAN, but LAN can access anything).