@anthoinn Problem resolved just need to put correct subnets on server side

VPN is much better way to access your resources from remote for sure ;)

If they are different interfaces and not switch ports - then no there is no way to put them on the same network without bridging them. But the only reason you need for them to be on the same network is broadcast traffic.. They could be on different networks and still access everything on the other network. Just create any any rules. Do these devices use some broadcast/multicast discovery or protocol that is required that they are required to be on the same network.. If want to leverage your ports for individual devices - ok... But why do you need to bridge them.. Just use 192.168.1/24 on 1 and 192.168.2/24 on 2.. And use an any any rule - there you go these devices can talk to each other for anything other than broadcast traffic. Bridge is only going to complex up the config, and more overhead for what? Are you doing something that requires broadcast to work? Then get a switch... Really the only time it makes sense to leverage a bridge is media conversion... Or I had something that required the devices to be in the same broadcast domain, ie the same L2 network.. But I also wanted to be able to firewall between them for some stuff. In that case you would use a bridge (transparent firewall) and be able to do such a thing. But just wanting to leverage the ports on your pfsense box.. I don't see the point of trying to bridge them?

My understanding from the breeze over I did of that article linked to - is you could send it to different servers based on name - but you need to use the proxycommand from your ssh client.. Which seems like more work then just using a different local domain or IP ;) and not bouncing off the proxy. That could come in handy if all your clients that wanted to talk to different ssh servers were outside your network vs doing a reflection connection from the local netework.

@viragomann i will try that, thanks :)

Hi @chpalmer, You were right; the problem was an incorrect gateway configuration on the webserver. Thanks again!

@viragomann Ok i got it working. It took some cleaning up after previous attempts and I wouldn't make it work if it wasn't for you info. Thanks

After another round of extensive troubleshooting, it turned out that everything I had done on the pfSense side was correct all along. The 1:1 NAT with static Outbound NAT rules were working perfectly fine. One thing I did not mention in my initial post, was the fact that I am also using DNS Resolver in my DMZ. This is done so that any softphone clients using my guest WiFi network, will be able to resolve the IP address of my PBX to the internal IP, rather than the external. While the PBX itself was configured with static IP address and using public name servers, it would somehow still resolve the PBX name to the internal IP, rather than the public IP. I don't know if there is a bug in the OS where FreePBX is running on, or a configuration error or something else. This is still a mystery to me, which I am trying to figure out.

In the time it took to fix this critical bug, I was able to: Set up and thoroughly test out OPNsense in a staging environment Find viable replacements for all the pfSense plugins and features I was using Weigh the pros and cons of switching to OPNsense Realize that open source pfSense has become a second class citizen Provision a new production firewall with OPNsense Manually copy the configuration from pfSense to the new OPNsense box Retire my pfSense box and switch permanently to OPNsense

@jimp Thanks for posting this. This is exactly my problem with my pfSense Plus. I have two WANs with my default one being GCNAT. My secondary WAN has a static IP which is used for inbound connections which need entry to my network. I didn't have any problems with 2.4.5p1. I can only make it work now if I change my default gateway to my static IP WAN. This connection is very slow compared to my other WAN. Hopefully they come up with a workaround soon.

Somebody please?

@operator2024 Hi I have same situation, no matter what I do I can't get a second phase 2 to come up when it uses a subnet that doesn't directly exist on a local interface. could you please tell me what exactly you did so i can compare with my conf in my case i have Palo Alto --- IPsec ---- Pfsense --- IPsec --- AWS Pfsense --- IPsec ---- Pfsense --- IPsec --- AWS both don't work could you please help

@werter OSPF - это уже лишнее в данной ситуации. Вопрос этот я решил через дополнительную фазу 2

Not sure if possible with udp.. And have never tried it with tcp either.. It is listed as an option, but not sure on the details of that option. We can call in maybe @Derelict he would have better understanding here of these options. I would think ;)

Do you see it being routed in packet captures or the state table when you try to reach 1.1.1.1? Where does it fail?

@viragomann thank you for the suggestion, I am gonna give it a try, we should fix the issue by having the remote endpoint add a phase 2 for the openvpn subnet but in the meantime this should fix it as well.

Auch der Reboot löst das Problem mit der fehlenden IPv6 auf LAN nicht immer. Da bleibt wirklich nur auf 2.5 zu hoffen. I am ready!