@bemethor Not really clear, what's the benefit of the link switching at all. pfSense is a stateful firewall. It requires to see the SYN packet of a TCP connection to pass the following packets. You can close the connection, when switching to the other link, so the client has to establish a new one. But this has to be done on the the openswitch. And it has the drawback that it slows down the communication. Alternatively you can circumvent the blocking of out of state packets on pfSense by adding a sloppy state rule to allow response packets without an existing state. But this could be a security impact. So you should at least restrict it to the certain source and destination. Since you intend to switch the connection in both directions you will need such rule on both nodes.

@stetsip [Your ISP] <====> <WAN-pfSEnse>[PFSENSE]<LAN-pfSEnse> <=={ this is your LAN } ===> <server> So, your "LAN" is the cable between the pfSense LAN port and the server network card. You don't need the second network interface on the <server> device.

Well, I've made a lot of progress ... now everything works except that OpenVPN and Wireguard don't take my DNS 9.9.9.9 configured in pfsense. I don't know where to force this setting for these two! Do you have any advice?

@nicolas-pissard said in Wifi Callings not working: However, When setting up things, keep everything simple - as basic as possible No MAC adding. No IP allow, nothing. Connect your device, check that you see the login page. Login with valid credentials. Check the pfSense GUI that you are logged in. Can you visit, for example google.com ? Can you visit ... www.tf1.fr (tf1.fr wasn't in your local D?NS cache, this test validates DNS lookups). @nicolas-pissard said in Wifi Callings not working: How to set up DNS port forwarding on NAT? You mean this : Redirecting Client DNS Requests ? Such a redirect is optional. True, there are people that 'insist' in using their DNS, not the DNS the device got by DHCP. That's actually their choice. A side effect is : they can't use the free (portal !!) wifi access at mac Donald's, neither Air France, neither SNCF. And yes, neither your wifi portal. It's their choice ;) Their choice can't be your issue. But, yes, I admit, I also feel bad for those people. So I actually did what was explained on that "Redirecting Client DNS Requests" : [image: 1686910802504-8a2ef651-3ff9-4d9b-85b1-c277e00c97e2-image.png] but again : this is not needed to make things work. It's just an anti-shoot-in-the-foot measure. These are the first 3 rules of my captive portal : [image: 1686911007559-ed23bcd1-9627-4445-afb9-efa69794f980-image.png] The first one is the firewall rule that was added by the NAT rule. As you can see, the counter in front of the rules are not zero : so this firewall rule (and redirecting) has been activated for some portal visitors. Most (low bud !) phones - or their even more stupid (sorry) owners insist on using their own DNS IP : they got redirected to ..... pfSense 127.0.0.1 so the resolver can do it's work for them. If this wasn't they case, DNS would not work for them (as initially the portal doesn't allow any external access !!). Happily enough : this is a small minority. The second rule authorizes express all DNS traffic to the pfSense Portal interface : these counters are way higher : which shows most devices to play by the rules : they use the DNS that pfSense DHCP has been given to them The third rule : This is a safe barrier. If I missed something then let them (the portal visitor) take the wall. This rule is never used, so I took care of all the port 53 TCP/UDP traffic. @nicolas-pissard said in Wifi Callings not working: Also I use DNS Resolver for blocking Domain Overrides. Just for my own curiosity : First : you add domain overrides. Then : you have to block them ? I have a domain override : [image: 1686912016972-4cffca0d-f7e0-4dd1-9ac8-f4b475be26e0-image.png] Where 192.168.2.1 is my pfSense portal IP network. I need to have a host name, as I'm using https portal login page. Http is pretty dead these days, and most browser just don't allow it anymore, or start to yell 'security issue ahead' ! Portal visitors will panic and say to you : "problem" ?! https usage is optional, of course.

[image: 1686865232828-screenshot-2023-06-15-at-2.40.04-pm-resized.png] (Blocked IPV6 as my ISP does not hand out IPV6 addresses only IPv4) Per Netgate docs "Ethernet rules can use Aliases for L3 source/destination matching but there is no support for MAC Address aliases at this time." This works and shows traffic. Each IP has its MAC recorded into the rule. Working config, Squid, Squidguard, Snort, Lightsquid, Auth-NTP, DNS over port 853, Clam-AV, UpNp for xbox alongside floating Queue CODEL this is functional and other ACLs are still working with this version. I have set the top line to block out all IPV6 Test now running for 24 hours no issues.

@ivanjrx Moderators can change the status for solved

Thanks

@alirz Not sure, but the alias should be in Diagnostics/Tables.

Folks - thanks to all for their input. The fact that the printer was trying to send to itself was causing some confusion. I configured the smtp in an app on another device on the same network (10.0.1.4.136) and tried sending. That failed as well. Checked the firewall logs ..... [image: 1686744653314-2e193d9b-db78-4abf-a643-fd0eab3c2042-image.png] .... the destination IP is the original printer we're having issues with!!! There had to be something on this firewall and sure enough, there was a rule in the Port Forward section to send traffic on 587 to 10.0.14.155 Deleted that rule - tested again and we're all good. Thanks again for your help.

@n1md4 rules apply to traffic arriving on the interface. They also apply in order. So on WLAN40 you probably want to: Block from WLAN40 Net to WLAN10 Net Allow from WLAN40 Net to any

@johnpoz OK, ty, yes. It turned out to be a password issue. Thank you for your help. Now I just need to figure out the fire panel.

Got this working in the end. It was a simple case of misunderstanding the difference between the actual interface and the label. I thought there was something special about the "LAN" interface. There's not, it's just a name, what's important in my learning was the interface (vlan in my case) that's assigned to the interface label.

@tcorney here is the whole other thread i have had for the past couple of days feel free to reply on this one https://forum.netgate.com/topic/180642/proxmox-web-interface-not-accessible-when-shaw-modem-is-in-bridge-mode/20?_=1686332965634

@JayS-0 said in OPT Network reachability issues: I have sorted this .. thanks to all. How so? Did you setup vlans and let pfsense see the tags by setting the vlan ID in esxi to 4095, did you setup port groups on your switch to isolate the vlans? Its not really good practice, nor do you actually isolate anything just running multiple layer 3 over the same layer 2. You should isolate them physically or with vlans. As to just a lab so just use any ole IP range you want - while sure you can technically do that. Its good common practice to use proper rfc1918 space.. Not like you don't have enough to play with, there is really little reason to use some public IP space that is not assigned to you specifically, etc.

@brunorocha__ said in DEBUG FIREWALL: but I don't know the command parameters Command line tools, these are the ones that use FreeBSD 14.2 as their base OS. freebsd man tail man stands for manual You can do this for any OS.

@bfeitell said in Firewall ALIAS import SHOWSTOPPER: checked for an update to the System_Patches package It is in there now.

Hi Rocco, Not sure it the same problem, but you may want to look at https://redmine.pfsense.org/issues/14396. It fixes the problem you are referring to for VTI tunnels, but the fix may be broader than that. / Christopher

@thecancel said in matching on vlan prio does not work as expected: Confirming that the RENEW is working: [image: 1686030422172-d25cedbb-bc17-48e2-b97f-8b2c4531a604-image.png] EXCELLENT :-) Happy to help