Topics

Hi all,

I'm working on an issue where several websites won't work. they resolve dns and everything, they just won't connect. It's as if opnsense is blocking them. I can;t see t in routes, firewall, web filtering etc.
If I curl from the console those sites load fast and fine. Anything behind that though has issues. It's only a half dozen sites.

Hi All,

I have nginx set up on my opnsense router. It works on the lan no problems at all, however, I cannot access the one server I want to be public accessable from the internet.

I see the client in the firewall logs coming from the test client's public ip going to the wan ip, but I don't see that in the access logs for nginx.
So nginx works from lan, traffic is getting to the firewall and should be getting to nginx.

Code Select Expand

IPv4 TCP * * WAN address 443 (HTTPS) * * Public SSL

Code Select Expand

IPv4 TCP * * LAN address 443 (HTTPS) * * Local HTTPS LAN to NGINX

Fiddler shows this:

Code Select Expand

fiddler.network.https> HTTPS handshake to home.norgan.net (for #399) failed. System.IO.IOException Authentication failed because the remote party has closed the transport stream.

Curl shows this:

Code Select Expand

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection

Firewall WAN rule log shows traffic:

Code Select Expand

clientpubip:53810 wanip:443 tcp Public SSL NGINX

I do have multi-wan, thinking maybe nginx isn't binding to the public interface and therefore we get an ss; handshake failure.

https://imgur.com/gallery/PWsbmjN

After much battling and trial and error, I finally cracked this last step of the azure routebased ipsec vpn.\

Basically, follow this https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route-azure.html then add the above rule. Left the wan links in for context with multi-wan.

Hi All,

Thought I'd share this config that I had struggled with for a few weeks. Something that OPNsense has finally provided a solution for.

The use case:
You have an internet connection, you have a fancy mobile phone with a super-fast 4g or 5g network. You are already paying for a bunch of data and live service. Why not just use that if your primary link goes down instead of paying for another service with separate data and monthly cost, only to be used on a handful of occasions throughout the year.

The solution:

Configure the wireless interface on your hardware hosting opnsense (and assume this also works on pfsense?).

Essentially, if you assign the wireless interface to the wan declaration in opnsense, it puts it into client mode and you can configure the interface to just connect to the access point, in this case, your phone's hotspot function, and use it as an upstream provider of internet connectivity.

All you need to do is turn on your hotspot and opnsense will connect to it and show it as a live gateway. 

How is it done:

WIP - sorry, I am working on the details for you. I will provide links to guides i used and the stuff I had to figure out. I will come back and put some details in. If you are interested let me know and i'll see what I can do to get info to you. Also, let me know if you found somewhere that showed how to do this, I wasn't able to find a concise guide for this particular use case.

Code Select Expand

2021-03-24T18:11:56 opnsense[5694] /usr/local/etc/rc.routing_configure: The command '/sbin/route add -'inet6' default ''' returned exit code '71', the output was 'route: : Name does not resolve'
2021-03-24T18:11:56 opnsense[5694] /usr/local/etc/rc.routing_configure: ROUTING: creating /tmp/re0_vlan99_defaultgwv6 using ''
2021-03-24T18:11:56 opnsense[5694] /usr/local/etc/rc.routing_configure: ROUTING: removing /tmp/re0_vlan99_defaultgwv6


If i reboot it works fine for a few minutes then this happens and I lose the ipv6 address on the wan interface and no routing to public ipv6 endpoints.

This seems to have been caused by the addiional of the DHCP_IPV6 interface in the gateway group. My intention was to failt to v4 if v6 fell over. It actually caused the v6 address to drop at dhcp renewal.

Hi all,
Things are humming pretty well, now time to iron out some wrinkles. I have a site 2 site IPSEC VPN to Azure set up. The Azure machines can get to the LAN on-prem but I can't seem to get back to them.

UPDATE: Guide followed, found one option I was missing. Everything is now in place, the link comes up, and my azure vm can send logs as per the inbound firewall rule.
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route-azure.html

The route is there, I've double-checked it. but I can't get traffic back to azure. It just routes out to the internet.

not sure what config or log is most useful. Still figuring opnsense out

I have a dual stack link and today I had no internet because the ipv6 wan interface had no IP address. I'm not able to properly evaluate it's state so the gateway group doesn't work.
Id like to have a ping working so i can monitor the link and flick back to ipv4 if ipv6 isn't working.


root@router:~ # ping 2401:d002:2302:b00:9ae7:f4ff:fe67:e871
ping: cannot resolve 2401:d002:2302:b00:9ae7:f4ff:fe67:e871: Host name lookup failure
root@router:~ # ping 2620:fe::fe
ping: cannot resolve 2620:fe::fe: Host name lookup failure
root@router:~ # ping6 2620:fe::fe
ping6: UDP connect: No route to host
root@router:~ #


Update: As I have come to understand, it seems the addition of an ipv6 gateway into a gateway group causes some ipv6 strangeness. I have taken the ipv6 gateway out of the group and things have settled.

OPNsense 21.1.3_3-amd64
FreeBSD 12.1-RELEASE-p14-HBSD
OpenSSL 1.1.1j 16 Feb 2021

Where do I start, I have a native dual stack link via DHCP ethernet wan (Cable modem).

Everything works, except for DNS. I have disabled unbound DNS and installed AdGaurd as that's what I was using before i got into opnsense. It works fine, but the IPv6 config wants to assign my quad 9 public DNS servers to the client which then does lookups on a public server rather than my lan local dns.

I've tried disabling it under settings for the WAN interface but still coming through.

Any ideas? I've searched a bit and can't find the cause for this particular issue.

UPDATE: I've since discovered deeper ipv6 issues and beleive this to be a downstream issue. No resolution.