OpenVPN Return Packets
-
I am having a strange issue with OpenVPN. Quick synopsis of the issue: from my laptop, I connect to the VPN and try pinging an IP address (lets say 192.168.68.10). Using tcpdump, I see the ICMP echo request packet hit tun0 … I also see an ICM echo response hit the LAN interface, which is then bridged with the WAN interface. Since the packet leaves on the WAN interface, it doesn't go back to the tun0 interface, so my laptop never gets the response. It seems from the routing table that packets destined for the VPN client network should go to tun0, but they do not.
Some more details: I setup a bridge between WAN and LAN, with the optional1 interface is being used for management purposes. The VPN uses 192.168.69.0/24 for client IPs. WAN is setup with an IP from the WAN subnet (192.168.68.1/24), which is what the laptop connects to for the VPN. The LAN interface is bridged with the WAN interface and is given a useless IP. I feel like this is not the best way to do transparent bridging but this is how I use to do it on older pfsense versions. I am running the latest 1.2.3 version.
Any thoughts?
Edited routing table:
netstat -anr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.a.b.c UGS 0 35808 fxp0 (Management)
10.a.b.c/30 link#1 UC 0 0 fxp0 (Management)
10.a.b.c mac_addy UHLW 2 289 fxp0 113 (Management)
192.168.68.0/24 link#3 UC 0 0 dc1 (WAN)
4.3.2.1/24 link#2 UC 0 0 dc0 (LAN)
192.168.69.0/24 192.168.69.2 UGS 0 0 tun0
192.168.69.2 192.168.69.1 UH 1 0 tun0Any thoughts? Any docs on doing OpenVPN with a transparent bridge?
-
What is the source of the ping?
If it is the actual IP of the client (in the WAN subnet) then the pfSense will just follow it's routing table and send the response according to it –> directly attached subnet --> transmit via WAN. -
The source of the ping is a client IP, 192.168.69.6. Its from the subnet 192.168.69.0/24, which is given to OpenVPN clients. From tun0:
tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
18:41:28.326657 IP 192.168.69.6 > 192.168.68.250: ICMP echo request, id 1, seq 252, length 40
18:41:32.946809 IP 192.168.69.6 > 192.168.68.250: ICMP echo request, id 1, seq 253, length 40From dc0 or dc1:
tcpdump -ni dc1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dc1, link-type EN10MB (Ethernet), capture size 96 bytes
18:38:56.904658 IP 192.168.69.6 > 192.168.68.250: ICMP echo request, id 512, seq 20157, length 40
18:38:56.921167 IP 192.168.68.250 > 192.168.69.6: ICMP echo reply, id 512, seq 20157, length 40.EDIT: changed IPs on the WAN to protect the innocent :)
-
Does anyone have any thoughts on this?
-
Hate replying to myself but apparently I need to setup routes on the servers … since this is a transparent bridge, traffic needs to hit the firewall for it to be encrypted, and not hit the default gateway which is on the other side of the firewall.
-
Hate replying to myself but apparently I need to setup routes on the servers … since this is a transparent bridge, traffic needs to hit the firewall for it to be encrypted, and not hit the default gateway which is on the other side of the firewall.
Yes, if it's not directed to an IP on the firewall, it won't route it. Without that, you're directing the traffic to the default gateway, which the firewall isn't going to route, it'll pass to the default gateway as it should (that's what the host is telling it to do by using that dest MAC).
