Does the script work on the latest version? It is very annoying that all VPNs remain on the backup line after the restoration of the main wan.

@johnpoz said in Is there an actual miniupnpd log spam solution?:

@inferno480 said in Is there an actual miniupnpd log spam solution?:

Aug 31 15:38:01 miniupnpd 59068 HTTP peer 192.168.50.5:40852 is not from a LAN, closing the connection

So I don't use UPnP.. But what is your lan network 192.168.50/24 ? Or is this some other network, and UPnP is only on lan? Or you have UPnP running on multiple interfaces?

If lan is seeing traffic from an IP that is not lan, I would expect for there to be barking about it.. You should not see traffic from IPs on lan that are not on the lan network..

What is the 192.168.30.x IPs - your also seeing those on the lan network?

Thanks for the quick reply -- I have several, separate LAN networks that need UPnP -- they are on different dot1q VLANs (e.g. ix0.30, ix0.50) represented as different OPT interfaces in pfSense as well (renamed to SONOS, and CAM respectively). They're all selected as UPnP client interfaces in the GUI. My actual 'LAN' is ix0.10 w/192.168.10.x/23.

@NogBadTheBad All connections origin from local lan.

@Blade1024 Not really following here.
You have a tunnel (IPsec or GRE) to AWS. You need to have all traffic that leaves pfsense, SNAT, to a 169.x.x.x address ? Why cant you SNAT it?
Or id imagine you create an IP Alias with the interface set to Localhost. Put in your 169 address there. Apply that to an outbound NAT rule (SNAT).

@Bob-Dig said in Routing of Gateway Group for VPN providers: Trigger level not working:

@MichaelAnders Activate E-Mail notifications if you don't already have. You will get lots.

Thanks, I enabled that now, test mail works. Let's wait and see :)

@eoin
Yes, this is why I suggested to do it with policy routing.

@t_k Let me see if I understand this.

You had 0.0.0.0/0 included in the list of "IPv4 Remote networks(s)" on the CLIENT side of a point to point OpenVPN link, running PFSense ?

If so, that is to be expected and your original configuration was wrong - 0.0.0.0/0 is the default route in a routing table, and setting it in the OpenVPN settings will cause the default route set in System->Routing to be overridden, but not reliably. There can only be one default route.

Something may have changed in 2.7.0 to make it work properly now.

We have a site to site OpenVPN link with PFSense at both ends, originally set up on 2.6.0 but now running 2.7.0, and unlike you I DO want ALL user traffic to go across the VPN and find its way out to the internet from there, (after additional filtering/inspection/logging at the main office site) and not go directly to the internet.

I actually had problems with 2.6.0 getting this to work reliably. The issue was that if you set the default route to the OpenVPN client interface only in Settings->Routing (setting Default Gateway IPv4 to the VPN tunnel interface) it does not seem to get reapplied if the OpenVPN connection drops and reconnects.

On the other hand if you set 0.0.0.0/0 in "IPv4 Remote networks(s)" in the OpenVPN client config, when the OpenVPN connection disconnected it would remove (clobber) the default route and not replace it, leaving it with no default route even after the OpenVPN connection came back up.

The workaround I came up with was to set the default route to the VPN interface on the client side in Settings->Routing AND push the default route from the OpenVPN server side by including 0.0.0.0/0 in "IPv4 Local network(s)" on the SERVER side, which pushes the route to the client side. (In fact I have all the local routes pushed from the server as well rather than defining them at the client side)

This is a workaround for what is probably a bug but it does seem to work in both 2.6.0 and 2.7.0 - from what you say behaviour when specifying a default route on the client side may have changed so that it works more as expected so I might not need to use my workaround of explicitly pushing a default route now.

This is solved, there was an issue on the WISP side, I also needed to run it as a /24.

@rcoleman-netgate Yeah, that would be nice. from what i have read from the Telus web site, it's a $400 add on. Cost to speed ratio was why i left my other internet provider. But the grass isn't always greener. :)

@viragomann And exactly that was the case/issue.

The VLAN contains my GuestWifi Clients. On the Unifi APs I had seperate LAN configured and in here there was "apply Guestpoliy" option enabled.

GuestWifiSettings.png

From there Ubiquiti Forum I had a description of what this feature does once enabled:

**Guest policies on VLAN will have firewall rules blocking that VLAN from all others and will apply L2 isolation.**

After that checkbox was disabled I can reach the LAN Subnet just fine.

Thanks for help folks!!

@BlazeStar https://docs.netgate.com/pfsense/en/latest/firewall/index.html#managing-firewall-rules

@mspeed OK, so I'd say that's not a DNS issue. The policy routing doc should explain what you want...that link and further up that page. I would think "bbc.co.uk" has multiple IPs/servers so you will probably have to compile a list of IPs yourself. If you put bbc.co.uk in an alias pfSense will resolve it every 5 minutes but I expect that would resolve to one IP.

I think the I found the issue ... sticky connection tracks connections by gateway and not by connection, this option doesn't seem to work if all the connections have the same gateway?

e70ebee9-d432-4e65-9a82-064a71c77295-image.png

Session tracking is all being routed to the same Gateway IP and thus means maybe any of my connections?

526ee23d-6eab-4095-91ff-662cf6cb64af-image.png

@AGA-0
Thank you. It worked very well with these steps in 2.6.0 but since upgrade to 2.7.0 error is occurring again:

Aug 7 11:27:35 (1691404055.938356) sockd[74692]: warning: new client from 192.168.13.5.62833 dropped: no resources

@navu I don't believe it is possible with a single Gateway.