There are lots of variables to dig though, but the first thing I would do is dedicate two NIC's to your VM. In other words, make sure the LAN interface has a dedicated NIC that is patched to your switch and isn't being shared with other VM's.

Recheck if your Siemens really need layer 2.
With layer 3 you could run any default Site to Site VPN like OpenVPN in tun mode.

-Rico

@t-np I'll second that...
I ve tried systat -ifstat 1
and I get correct stats like this
6652a2e9-830c-4eea-93ac-2a53c81f4506-image.png

But only this on dashboard
0d1fe276-9f8c-40af-9d72-3ed89c1dc3c5-image.png

I'm also on vlans

@viragomann
Ah, yes those devices do indeed have Windows firewalls on. I thought you meant like actual firewall hardware. My bad. :)

I'll check those too. Anyway, here are the subnet infos I promised.

WAN 1000baseT <full-duplex> 84.*********
LAN1 1000baseT <full-duplex,master> 10.0.0.1/28 (10.0.0.1 - 10.0.0.14 range / 10.0.0.10 - 10.0.0.14 for DHCP)
LAN2 none ......... 10.0.0.17/28 (10.0.0.17 - 10.0.0.30 / Fully allocated for DHCP)
LAN3 1000baseT <full-duplex> 10.0.0.33/28 (10.0.0.33 - 10.0.0.46 / Fully allocated for DHCP)
LAN4 1000baseT <full-duplex> 10.0.0.100/27 (10.0.0.97 - 10.0.0.126 / 10.0.0.101 - 10.0.0.126 for DHCP, 10.0.0.101 Static Leased for Access Point)

@Fehler21 said in Sharing WANs between 2 Pfsense Routers:

you have a dedicated interface/subnet for routing between the two pfsense via the Ubiquiti bridge.

Yes I Do.

Thanks for the info, I will give it a shot and report back.

Thanks!!!

Thanks mate, I'll give a go. Cheers.

Eoin

@Gertjan

yessssss and a pain in the a*%&§ when u ignored that uu knowed it

Covered in jimps Multi WAN hangout: https://www.netgate.com/resources/videos/multi-wan-on-pfsense-23.html

-Rico

Same on my pfSense box.

As a workaround you can edit /cf/conf/config.xml using "Diagnostics -> Edit File" and change the order directly in the config.

Hi,

@0daymaster having the same issue, I did a quick & dirty implementation of multiple ping targets for 2.4.4-p3. I can give you the patches if you want. However there is dpinger to pach/recompile aside to support multiple targets, which can be quite tedious if you're not familiar with freebsd and if you need to cross-compile (for arm in my case). With the patch, dpinger will ping each host as often as it was before and will report an average on all hosts. So, if you set 4 hosts, it will generate 4x more pings in the same time, and if one host is down, it will report 25% packet loss.

As a side note, it has been a surprise to see that dpinger is using threads with shared variables without any kind of thread synchronisation. If there is any issue there (and I think there is), using X hosts will multiply by X the likelihood to trigger it.

There is nothing special about it.

They are just addresses.

You should disable NAT for the public addresses in use on the inside.

Well incoming pings work from the outside but now no traffic originating from the inside can get out. When I turn off the firewall it all works. pfctl -d

Do you have rules passing the traffic into that interface from those hosts?

@runDMG Gotcha! Yeah, your issue was different than what Im facing :)
@Cool_Corona Hi! I haven't installed any packages and its a fresh install. I've created a topic with my specific issue here: https://forum.netgate.com/topic/152536/arp-00-11-22-ab-cd-ee-is-using-my-ip-address

Cheers!

Thanks. I will try this.

See if any of the following helps.

https://docs.netgate.com/pfsense/en/latest/book/firewall/methods-of-using-additional-public-ip-addresses.html

https://docs.netgate.com/pfsense/en/latest/book/routing/routing-public-ip-addresses.html#

Interesting - I only know host routes with mac addresses as Gateway if a direct connected route within the same subnet exists, but all your routes within 1.2.3.X have /32 masks. Did you compared the mac addresses with these from a "working" routing table. Does the macs in the routing table matches the entries in the arp cache? At the moment I have no clue whats going on at your end nor what could be the root cause of your issue 😕
I must say I don't have much experience with pfSense 2.4.5, since I was hitting latency issues and instability with BGP routing when I installed it on my OVH VM . But general reachability for the default route was not an issue after reboots, so I didn't look closely into the routing table for that part. Also I rolled it back to 2.4.4_p3 pretty quickly due to the problems I had. All my installations are running on 2.4.4_p3 at the moment.
If you have capacity on your proxmox cluster and another free IP-Addresses, I would suggest you provision another pfSense installation for test purposes and see if situation stays the same when you configure it from scratch.

Sorted out. I think I got my LAN rules wrong.