@viragomann

Thank you. Searched the config file and found a few rules that had the old GW specified that did not appear in the GUI. Updated and monitoring.

@LB-0 said in Traffic goes where ?:

@Jarhead No change when enableing that rule and there should not be a need for any rule on the SERVER nic since the traffic originates from the LAN and pfsense is a stetefull FW.

Very true but if the return traffic was going out the WG tunnel, there would be your problem. By disabling that rule you should have gotten rid of the tunnel path and you would need the rule above it to make sure that subnet still had access to anything while testing.

As Viragomann said, start sniffing. I'm still betting the return traffic is hitting the WG tunnel. You can sniff on it and see if the packets are forced that way.

@viragomann What I mean is I can see the traffic leave one router and enter the other but I cant establish the full connection. Basically Router A devices request data from a Router B device Device from router A will make it to Router B device but Router B device does not respond back. I have also tried this in reverse (Router B to A) and I cannot get 2-way communication.

I will have to work on the packet sniffing later. Thank you for the help!

@Gertjan

/var/dhcpd/var/db/dhcpd.leases type-O in my post missed the s

this file was almost empty in mine

@Gertjan said in Assign static IP to dhcp device fails:

You mean you actually saw in the DHCP log that de device REFUSED the IP given to it by pfSense ?

Yes it showed the static mapping AND it showed up in the ARP table. However it refused to take the IP unless MAC address AND client identification is filled out
even though client identification says "optional" its not so optional. When I say refused it was popping up in the DHCP as a dynamic assigned IP (192.168.3.58) instead of the static I assigned (192.168.3.3). I used wilcard * for the client identification and it worked fine.

I then changed the client identification to the same value as the mac address and it still seems to work.

@johnpoz this fixed it... https://help.ui.com/hc/en-us/articles/16230412350487-UniFi-Isolated-Devices

but I really could use some help setting up my pfsense firewall rules correctly, lol. thank you so much for helping me John.

Appreciate it guys i will take a look and test

@johnpoz Hi, any other suggestion which could be tried to get this working correctly?

@mcury Thank you very much for your help.

Finally!
The solution was creating a firewall rule that route the traffic of my Bridge interface through the gateway i have created for the wireguard client.

@SecureCPU - I would check out the DNS section in the multi-wan documentation, and compare against your current configuration:

https://docs.netgate.com/pfsense/en/latest/multiwan/interfaces-and-dns.html

How exactly do you have your DNS configured? Are you using DNS in resolver or forwarding mode?

Hope this helps.

@bonilha
That's correct, this is not useful for a VTI IPSec connection. But you didn't mention that it's a VTI before.

So in this case, the static route should be sufficient to route traffic from pfSense itself to the remote site.

@jcyr using a /25 vs a /24 is not a "hack" hehehe

But to be honest use of 192.168.1 or even say 192.168.0 can be problematic - these are 2 of the most common networks. So you run into stuff like your seeing with your ATT devices IP address. You can also see issues with remote access via vpn where the remote site is also using the same IP range your using and then have problems accessing stuff via the vpn.

Using the 192.168.1 could also lead to problem if you fire up some new device on your network and it defaults to using say .1 or .254 and that ends up stepping on say pfsense IP..

You were better off just using 192.168.2 network, or if you like the 1 there as the 3rd octet.. Use maybe 172.16.1/24 or 10.1.1/24 or 192.168.10/24

But using a /25 can work.. for your current setup, but could also be problematic because I doubt your ATT device is using a /25 and you could still run into a issue. If it happened to say assign your pfsense wan the same IP in your /25 as your lan side network interface..

Your better off just moving to some network on your pfsense lan that in no way is overlapping with the network your ATT device is using.

@arkoulikosta said in routing to secondary gateway:

@Gblenn said in routing to secondary gateway:

@arkoulikosta What do you mean with "access to" secondary gateway?
Do you simply want to access the upstream router and manage that via it's UI.
Or do you want to route traffic that way?

The first part is as simple as typing in it's IP in your web browser...

If you for example want to have your PC use WAN2 for internet access you can create a simple rule on the LAN interface for that.
Your source will be the IP of the PC and destination is Any. If you expand the Advanced section, there is an item calle Gateway with a dropdown where you will find your WAN2 in the list. That's pretty much it...

Perhaps it can be done in a different way but that's how I did it when playing around and testing this.

i wanted to access the router ui, but could not do so if the wan1 gw was active
and it was indeed as simple as adding a rule with the wan2 gw as default.
thank you!!
Good that it works, but if it is just the UI that you are trying to access, I don't see that you need to create a policy rule for that...

I have a similar setup, where my second WAN (failover) is connected to a 4G router which hands out a 192... IP to pfsense. It looks like this and I access that router UI directly just by typing in the IP on any browser (192.168.3.2 in my case). There is no need to have any policy rule in order to access that subnet.

39863ca2-736f-4ef2-b1dc-2b70b3c68107-image.png

You should be able to reach both upstream routers from your LAN, as long as both are considered UP.

@johnpoz adding a dns redirect as a workaround helps for now. https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

I just double checked on other pfSense hosts I am managing. On all of them the above dig@ command works without issue. The only real difference is that they are all single WAN.

I'd consider this somewhat solved for now, but I will have to investigate this behavior further, it seems I am missing something more or less obvious.

Anyways thanks for your assistance! ☺