That bug seems to be unrelated. At least to the packet capture above. It's not failing to NAT traffic there just opening a stream to the wrong location. The only place it could have got that from (unless it's hard coded into the server) is from the client.

Steve

No. That capability does not exist. You will have to manually monitor and disable the gateway when the cap is reached.

Wanted to provide an update to my own thread - after doing research it seems that OSPF will not create an automatic source/outbound NAT. So, it would seem that the "fix" would be to create automatic outbound NAT AND manual (hybrid mode), but this kind of defeats the whole point of OSPF. I could do a summary NAT, but then still, the benefit of OSPF would not be fully realized. Hrm.

When that is the case it is customary to duplicate the steps to repeat the condition and report it, so the developers have something to work with regarding your specific set of circumstances.

I understand it is a burden. Sometimes it is easier to just say, "it's a bug, fix it."

You only need an outbound NAT rule for that. Firewall > NAT > Outbound

If your outbound NAT is in automatic mode switch to hybrid first. Then add a rule:
Interface: IoT
Destination: 10.10.30.10 (the cam)
Translation address: Interface address.

Rules to allow access have to to be add to the interface where the connections come into pfSense, here it is the core.

https://www.netgate.com/docs/pfsense/nat/accessing-port-forwards-from-local-networks.html

well yeah its simple copy there is no magic saying oh your copy me from lan net to opt net need to change the source..

Correct yourself. Change it to optX net or whatever you rename that opt net to be... I always change mine to something that makes sense to me. wlan net, dmz net, dtv net, etc.

@jimp that's good news! I'm have researched looking for an solution and become here to post as last resort(because my english writing), fine both side are pfSense i'm happy to use it. While i will keep routing policy by hand a way statistically by adding hosts or networks according my needs. regards

Looks strange for me. That are only the states. Why don't you post packet captures, which are more informative.

when I watch the states of one of the test servers, it looks like this:

LAN tcp x.x.0.96:45922 -> x.x.0.50:80 (x.x.x.148:80) CLOSED:SYN_SENT 4 / 0 240 B / 0 B

This shows up multiple times, but it still receives the same error. I am not seeing it go through the gateway anymore though (Instead of LAN it used to say the GW name)

@amundae IPsec traffic selectors are not in the routing table because they are not routes.

https://forum.netgate.com/topic/131420/routed-ipsec-using-if_ipsec-vti-interfaces

Yeah why not just use 1 pfsense, put your different companies on different networks and then just limit bandwidth or better just rate limit them at the switch level.

yes when you put hosts on a transit you have to route on them as well.. because hosts do not belong on a transit network only routers do..

Having pf on vm's gives another layer of redunduncy, but thats another story.
Maintaining one system does have its benefits (upgrades, troubleshooting etc)
And routing the packets in and out of virtual interfaces does consume unnecessary cycles. I can't tell if this has any measureable degradation whatsoever in any case.
I do have second thoughts if that would work in the end, becauseit all boils down to a common routing table so traffic would never pass through the lans :(

It sounds like you do need the functionality of a managed switch. I recently went through this myself. I'm not a professional network engineer but I do understand networking reasonably well. I can help translate what the pros here are saying because I'm not one of these guys .. they know their stuff.

What might help this discussion is to understand your needs a bit more clearly.

How many VLANs do you anticipate? How many clients/ports do you need to support per VLAN? How are you running pfSense? Is it a Netgate appliance, home built, in a VM?

I can safely verify that in 2.4.3-RELEASE-p1 (current stable) works as it should
One interface is left with the dynamicly selected monitor peer and the other
pings a stable ip inside the provider (in my case the cluster ip of the main dns stack)
If the provider changes her policy and blocks ping that would be an issue, but I think I can live with that. :)