ok, thanks for the help. i have it sorted. and Vlans worked PERFECTLY.

Cheers

Jason

Sorry for making you so upset. TBH, I thought the info above was OK, and you initially seem to grasp that, but obviously I have annoyed you for some reason, and for that I can only apologise

As mentioned, the issue was at the layer 2 level with ARP and the response for some reason not making it back to client when querying the gateway. This was a genuine query but I fear it has has deteriated.

Once again, thank your for you input.

Actually, that's default behavior of the XG-7100. Lagg0 is an aggregate of ix2 and ix3, interfaces internal to the chassis that provide trunking for the 8 ports on the front face.

lagg.png

@noplan

done the same again like the pen and paper check

took the same switch (old habits die hard)

same problem --> wtf

took a brand new switch

workin like a charm

checked the old switch .... some crazy folk just done some MAC ACL testing on some random ports
reset the old switch now workin like a charm
so SOLVED

This one on your proxmox - is this doing nat? What your doing is correct.

I would go through the troubleshooting doc.
https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

What your doing is fine you can have multiple IPs sending to port 80 behind... I would validate that traffic is actually getting to pfsense wan, and then sending it on... This can be done with packet captures on pfsense, under the diag menu..

If I had to guess its your proxmox setup - firewall maybe on it? And access from other than your local network?

Did you setup the vip correctly? When you do a vip, it should be available via your dropdown when you do port portward..

example..

vip.jpg

And the mask should be what your network on your wan is using.. Do you have like a /29 or something? Where this address block is coming from?

Have a cocktail.

Done and Done Much appreciated

Thank you both very much!
I added the NIC and then rebooted the first time. Now I've followed your advice which worked like a charm.

If the DHCP server was giving you bogus DNS servers you can expect delays in anything on the firewall that was looking to resolve names. Totally normal.

@hsv said in Debugging static routes:

How do I pass the traffic into the transportvlan.

Pass rules on the transportvlan interface.

I have no idea what a static rule is.

You just made it make sense.

I had been going over and over about going around the default route but I kept coming up with nothing because traffic was going to the Internet (AKA the default route), therefore it had to take the default route to get there. It made no sense. ☹️

Thanks a million for your help!

@planedrop Yep, recognize you from the Unifi forums. Running pfSense in front of my UDMP has worked out great once I sorted out the Outbound NAT rules. For the last 30 days, I haven't had a need to touch anything in pfSsense, it just works.

So other than load balancing my 2 WANs, I don't do anything on pfSense, everything else is happening on the UDMP. I don't have any port forwarding in place right now as I don't really need it, but my VPN to my work machine on a corporate network (using Cisco Anyconnect) has been working flawlessly from my personal home workstation.

That said, I would imagine that in order to make port forwarding work properly, one would have to make entries on both the UDMP as well as in pfSense and I'd imagine pfSense will let you make port forwards sticky on one WAN or the other.

As I mentioned on the UniFi forum, once I get my dual symmetrical GigE WANs up and running, and be doing some benchmarks from machines behind the UDMP, as well as from a box hanging directly off the pfSense appliance.