@viragomann

Hey so, I finally got to this and I did the following:
I went to System > Routing and setup a new gateway
10.1.4.13 -> This didn't work when I went to the status tab it showed this route as offline so I changed it to (FYI this is the current IP assigned to the DreamMachine WAN Port)
10.1.4.1 -> This immediately showed as online

I then went into Static Routes and did the following:
Add -> Destination Network 10.1.1.0 / 24 -> Gateway 10.1.4.13 -> Didnt work tested with ping and VPN no response. Then did
Add -> Destination Network 10.1.1.0 / 24 -> Gateway 10.1.4.1 -> Got a response through ping but seems to be redirecting and I cannot see the machines in VPN

PING 10.1.1.1 (10.1.1.1) from 10.1.4.1: 56 data bytes
92 bytes from 10.1.4.1: Redirect Host(New addr: 10.1.4.1)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 1747 0 0000 3f 01 0100 10.1.4.1 10.1.1.1

92 bytes from 10.1.4.1: Redirect Host(New addr: 10.1.4.1)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 1747 0 0000 3e 01 0200 10.1.4.1 10.1.1.1

92 bytes from 10.1.4.1: Redirect Host(New addr: 10.1.4.1)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 1747 0 0000 3d 01 0300 10.1.4.1 10.1.1.1

92 bytes from 10.1.4.1: Redirect Host(New addr: 10.1.4.1)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 1747 0 0000 3c 01 0400 10.1.4.1 10.1.1.1

FYI just wanted to test the default network since i cant even access the DreamMachine

@viragomann I will try and replace the cable monitor it. Thank you for the reply.

@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.