Some more info...

I am trying now to reconfigure my system by getting rid of all the VPN configuration and redoing it..

However as one last thing, I was going to try was removing my VPN Gateway and recreating it and subsequently assigning a VPN interface to it.

However when I did that, my Internet access stopped working. i.e. the WAN_PPPeO gateway was removed under the covers!

I wonder if this is the problem I am experiencing above:

There is something weird in that the Gateway link on my rule shows that correct VPN gateway, including a red status when I hover over it, but when I click the link it opens to the WAN_PPPOE Gateway definition, not the VPN one.

Which leads me to believe there may be something that happened during the upgrade? I even recreated the rule from scratch, with the VPN gateway selected, but it still clicks through to the WAN_PPPOE gateway?

For clarity, on the Rules/LAN page where I have my rule to direct certain hosts to the VPN Gateway. it shows that I have my VPNgateway selected for the traffic. If I hover over the VPN link for the rule, It shows the VPN gateway state.

But when I click on the VPN gateway link, it opens to the WAN_PPPoE gatweway definition, not the VPN gateway definition? if I inspect the link, the URL points to the actually WAN_PPPeE gateway with id=3 whereas the VPN gateway is actually id=2?

I wonder if the backup/restore of my configuration is just screwed and I need to start over?

Any ideas here?

@kamil-0 opcjach serwera OpenVPN odchacz opcję "Inter-client communication". Komunikacja między klientami nie powinna działać. Ale jak wrócę do domu to sprawdzę.

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?

OK, I worked it out!

I had the following Firewall rule for LAN:

Screen Shot 2021-04-06 at 8.17.46 pm.png

But of course, the 10.8.0.0/23 and 10.9.0.0/23 (I changed them to /23 instead of /24) are not in the "LAN Net", so I had to add extra rules to allow that traffic out:

baecb64d-b9fb-4d84-b216-035dbd903399-image.png
That as well as the static routes fixed it!

IMO it's impossible to tell active directory domain member to not look for dns record of domain name.

Hallo Zusammen,

vielen Dank für die vielen Antworten.
Ich werde das ganze am Wochenende mal trennen.
Das macht Sinn ja. :)
Aktuell komme ich nur nicht dazu, weshalb das ganze hier etwas eingeschlafen ist.
Bei einem anderen Peer klappts scheinbar.
Sehe merkwürdig.
Aber ja, trennen macht sinn.

Danke erstmal.

@ddbnj said in Cannot access beyond router via OpenVPN:

10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

Yeah that would dick it up ;)

Glad you got it sorted! Told you it wasn't pfsense ;) hehehehe

The trick is getting the person to clearly see that themselves... Which is why the sniff proves to the user, hey pfsense is doing what its suppose to be doing... Have to look elsewhere..

@Derelict I think i got it to work. After i set the default gateway manually to the VPN and not automatic and saw that it worked,
i transfered the Flowing Rule i made for the outbound traffic to the Lan interface.
With the new knowledge of your help and the help of viragomann i changed some tiny things in the firewall rule.
After that i changed the default gateway back to automatic and know the outbound traffic takes the vpn and everything works.
I even rebootet the firewall to get lost of the states but everything still functions as it seems.

Thank you so very much for your dedication and your help.

@paul-heidenreich-0
Outbound NAT doesn't work with policy-based IPSec tunnels. You have to do the NAT inside IPSec.
It should work with VTI IPSec, however.

If you have already a phase 2 to for the NAT-IP or subnet at the remote side, an additional is not needed in most cases.

You have always have to add the remote networdk to the "local networks", no matter if you use BINAT or outbound NAT.

That's correct. But you didn't mention, that you have already done this.

Just realized that i posted in the wrong section - going to repost in the right section.