@johnpoz

thanks for the info, yes i had 1 device to ping in other side.
I think it's already working now.

Thanks for the advice.

cheers

@DanBlackaz yeah let it run for a while - if you were seeing them every 1 to 4 minutes and now have 10, yeah could be a indication its gone - but lets give it a day or so..

It could be some oddness with mptcp and or pd, not sure how deep pd has gotten into all the different 5g networks out there. Or even mptcp - but you tie those sorts of technologies along with anycast.. And yeah would expect some duplicate stuff to show up now and then for sure..

In the big picture some duplication isn't going to cause any issues, other than log spam.. But log spam is a real thing that can be problematic for sure. You fill your log with garbage its way harder to spot things that could be indications of real problems, etc

Why I don't log default deny, and only log common udp ports in for may wan blocks, etc.. Reduction of log spam.. I don't need to see some rando UDP port hitting my wan, or a bunch of FA or etc.. But I do want to see syn to my wan IP, and there are a lot of common UDP ports that could be of interest.. So that is what I log, specific UDP traffic I would want to see and any SYN traffic sent to my wan IP that is blocked..

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