@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.

A brief update on the issue:
I did a several tcpdumps to see how traffic traveled through the machine.
pings from the Raspberry Pi 10.0.1.253 to 172.17.20.130 are sent to the ipsec interface and receive replies:
tcpdump -i lagg0.100 icmp

14:22:27.875175 IP 10.0.1.253 > 172.17.20.130: ICMP echo request, id 8761, seq 14, length 64 14:22:27.899031 IP 172.17.20.130 > 10.0.1.253: ICMP echo reply, id 8761, seq 14, length 64

These in turn are encapsulated:
tcpdump -i enc0 icmp

14:23:23.969153 (authentic,confidential): SPI 0x82bee771: IP 10.0.1.253 > 172.17.20.130: ICMP echo request, id 8761, seq 70, length 64 14:23:23.992999 (authentic,confidential): SPI 0xc030c198: IP 172.17.20.130 > 10.0.1.254: ICMP echo reply, id 21640, seq 70, length 64

We see the requests going out as 10.0.1.253 and replies coming in for 10.0.1.254, which are then translated back to finally be delivered to the Pi.

Now, when repeating this check with an OpenVPN client, we see different behavior:
tcpdump -i ovpns7 icmp

14:27:13.375762 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 13598, seq 1, length 64 14:27:14.383797 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 13598, seq 2, length 64

Requests go out, but nothing returns. Let's see where the requests go:
tcpdump -i enc0 icmp yields nothing, so let's try WAN:
tcpdump -i lagg0.4090 icmp

14:30:10.318176 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 30820, seq 3, length 64 14:30:11.326380 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 30820, seq 4, length 64

Now it's getting interesting: the pings from OpenVPN clients are sent to the default route (WAN). If I change the NAT rule's interface from IPsec to WAN, the translation also shows up in the tcpdump output:

interface: WAN address family: ipv4 protocol: any source: 192.168.248.0/24 destination: 172.17.0.0/16 NAT address: INT_IP (10.0.1.254) Pool options: default

Let's try the tcpdump again:
tcpdump -i lagg0.4090 icmp

14:33:12.248168 IP 10.0.1.254 > 172.17.20.130: ICMP echo request, id 15552, seq 1, length 64 14:33:13.251668 IP 10.0.1.254 > 172.17.20.130: ICMP echo request, id 15552, seq 2, length 64

So the firewall is correctly performing outbound NAT translation for 192.168.248.0/24->172.17.0.0/16 as 10.0.1.254, but the traffic is routed from the OpenVPN interface to the default gateway (WAN interface / lagg0.4090) rather than to the IPsec tunnel for encapsulation.

The whole point of wanting to use outbound NAT for traffic to 172.17.0.0/16 is so either side only needs to define one P2 entry, but we can set up multiple OpenVPN tunnels (with each a different subnet) that can all reach that remote network.

Would anybody know a trick / way to force traffic from 192.168.248.0 to 172.17.0.0/16 to go via the IPsec interface (enc0) rather than the default gateway (WAN/lagg0.4090)? I've tried creating a bogus gateway under System/Routing/Gateways and creating a static route under System/Routing/Static Routes for 172.17.0.0/16 via this bogus gateway, but this only resulted in all traffic from ovpns7 meant for this subnet to get put through a loop until the TTL expired.

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