offloading OpenVPN using external gateway
-
@bingo600 no no, sorry, it is only the description. Ignore it.
-
Is that rule all the way at the top ?
-
@bingo600 yes, sure
-
@chrispazz
I have to pull in the tuff guyzz now.@stephenw10
Any ideas here ?? -
But just to summarize :
You say if you put a PC on the 192.168.5.x lan , and set 192.168.5.99 (RasPI) as def-gw , the PC can use the RasPI & OpenVPN tunnel ok ?
You have put all desired OPENVPN PC's in a IP HOST Alias
You made direct host entries in the rule, and made Policy based rules with the RasPI as Gateway , on all the interfaces where a "OPENVPN" PC could be connected ?But the pfSense won't match the source ip's, and therefore won't policy route t the RasPI. This is also confirmed by , enabling logging in the Policy rule. And no loglines appear.
Q:
We did a trace (the first one above) , where we succesfully matched a ping to google.it , and you got both loglines , and we saw the policy routing in effect in the pfSense packet trace.What has changed in the pfSense config since that ?
Was that test also made with the iMAC ?
Q:
You do use either static IP's or DHCP MAC Lock (Reservation) , in order to ensure that the PC's used for test & OPN always get the same ip ?. -
@bingo600 said in offloading OpenVPN using external gateway:
But just to summarize :
You say if you put a PC on the 192.168.5.x lan , and set 192.168.5.99 (RasPI) as def-gw , the PC can use the RasPI & OpenVPN tunnel ok ?
Yes, correct.
You have put all desired OPENVPN PC's in a IP HOST Alias
You made direct host entries in the rule, and made Policy based rules with the RasPI as Gateway , on all the interfaces where a "OPENVPN" PC could be connected ?Yes.
But the pfSense won't match the source ip's, and therefore won't policy route t the RasPI. This is also confirmed by , enabling logging in the Policy rule. And no loglines appear.
No. The rule is correctly engaged and it is logged in firewall log but it seems to ignore the Raspi used as gateway.
Q:
We did a trace (the first one above) , where we succesfully matched a ping to google.it , and you got both loglines , and we saw the policy routing in effect in the pfSense packet trace.Currently, using 192.168.5.9 (Raspi gateway) as host, trace display the following when doing a ping to www.google.it:
19:32:03.251588 IP 192.168.5.1 > 192.168.5.9: ICMP echo request, id 43267, seq 26591, length 9
19:32:03.252028 IP 192.168.5.9 > 192.168.5.1: ICMP echo reply, id 43267, seq 26591, length 9Doing packet trace using google IP as host gives the following:
19:33:38.627397 IP 192.168.5.1 > 172.217.168.3: ICMP echo request, id 10411, seq 0, length 64
19:33:38.642607 IP 172.217.168.3 > 192.168.5.1: ICMP echo reply, id 10411, seq 0, length 64Was that test also made with the iMAC ?
The packet tracing is done pinging from Imac to www.google.it
Q:
You do use either static IP's or DHCP MAC Lock (Reservation) , in order to ensure that the PC's used for test & OPN always get the same ip ?.I have IP reservation for iMac and static IP for Pfsense.
Just to give you more confirmation about the rule catched, consider that without that new rule, the connection has to go via the pfsense VPN client.
If I deactivate the rule, the connection go with pfsense VPN client. if I enable the rule, the connection exit with ISP gateway (no raspi VPN). -
@chrispazz said in offloading OpenVPN using external gateway:
packet trace.Currently, using 192.168.5.9 (Raspi gateway) as host, trace display the following when doing a ping to www.google.it:
What does that mean ?
Currently, using 192.168.5.9 (Raspi gateway) as hostWasnt the RasPI 192.168.5.99 ?
What does as host mean (you mean you ping the raspi) ?
The below 2 traces both show a req & a reply
19:32:03.251588 IP 192.168.5.1 > 192.168.5.9: ICMP echo request, id 43267, seq 26591, length 9
19:32:03.252028 IP 192.168.5.9 > 192.168.5.1: ICMP echo reply, id 43267, seq 26591, length 9Doing packet trace using google IP as host gives the following:
19:33:38.627397 IP 192.168.5.1 > 172.217.168.3: ICMP echo request, id 10411, seq 0, length 64
19:33:38.642607 IP 172.217.168.3 > 192.168.5.1: ICMP echo reply, id 10411, seq 0, length 64In the Packet capture try to set detail to high or full
We need to see the mac addresses in those packets.
And compare to the RasPI mac address
-
@bingo600 said in offloading OpenVPN using external gateway:
What does as host mean (you mean you ping the raspi) ?
HOST is the captured Host address
We need to see the mac addresses in those packets.
b8:27:eb:8e:00:43 is Raspi MAC Address
02:11:32:25:4e:f9 is pfsense WAN interfaceFull detailed trace is the following:
192.168.5.1 > 192.168.5.99: ICMP echo request, id 43267, seq 28884, length 9
19:51:42.213831 b8:27:eb:8e:00:43 > 02:11:32:25:4e:f9, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 59852, offset 0, flags [none], proto ICMP (1), length 29)
192.168.5.99 > 192.168.5.1: ICMP echo reply, id 43267, seq 28884, length 9
19:51:42.723672 02:11:32:25:4e:f9 > b8:27:eb:8e:00:43, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 64, id 65165, offset 0, flags [none], proto ICMP (1), length 29) -
Now do the same trace with the google ip as the destination
Your iMAC isn't multihomed ?
I mean both cable & WiFi -
@bingo600 here it is:
192.168.5.1 > 216.58.215.227: ICMP echo request, id 61288, seq 0, length 64
20:09:20.262578 dc:39:6f:f2:4d:e4 > 02:11:32:25:4e:f9, ethertype IPv4 (0x0800), length 98: (tos 0x60, ttl 113, id 0, offset 0, flags [none], proto ICMP (1), length 84)
216.58.215.227 > 192.168.5.1: ICMP echo reply, id 61288, seq 0, length 64
20:09:21.238644 02:11:32:25:4e:f9 > dc:39:6f:f2:4d:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 58651, offset 0, flags [none], proto ICMP (1), length 84)Trying to understand who is dc:39:6f:f2:4d:e4....
Currently iMac is connected only with wifi so no multiple ip
-
@chrispazz said in offloading OpenVPN using external gateway:
Trying to understand who is dc:39:6f:f2:4d:e4....
My money is on the ISP router 5.254
pfSense Diagnostic -> arp table will reveal
-
@bingo600 you are right!
-
In the capture , strange it matched ....
didn't you set 192.168.5.99 as ip match ? -
@bingo600 latest try was with google IP as you asked....am I wrong?
-
@chrispazz said in offloading OpenVPN using external gateway:
@bingo600 said in offloading OpenVPN using external gateway:
What does as host mean (you mean you ping the raspi) ?
HOST is the captured Host address
We need to see the mac addresses in those packets.
b8:27:eb:8e:00:43 is Raspi MAC Address
02:11:32:25:4e:f9 is pfsense WAN interfaceFull detailed trace is the following:
192.168.5.1 > 192.168.5.99: ICMP echo request, id 43267, seq 28884, length 9
19:51:42.213831 b8:27:eb:8e:00:43 > 02:11:32:25:4e:f9, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 59852, offset 0, flags [none], proto ICMP (1), length 29)
192.168.5.99 > 192.168.5.1: ICMP echo reply, id 43267, seq 28884, length 9
19:51:42.723672 02:11:32:25:4e:f9 > b8:27:eb:8e:00:43, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 64, id 65165, offset 0, flags [none], proto ICMP (1), length 29)What command did you use on the iMAC to make this trace , where it goes to the Raspi (but raspi as destination)
-
@bingo600 only "ping www.google.it".
But in first trace I used the raspi as Host capture.
-
Ok this is interesting:
I added a floating rule with no filters but "out" direction and in advanced settings with the Raspi Gateway.
With this, the connection go correctly thru the Raspi VPN.
So, the external gateway thur pfsense is working correctly.
I have to understand why when using a firewall rule in a specific interface is not using Raspi gateway -
@chrispazz
I don't think the first capture is showing the : ping www.google.it
I think something is pinging the Raspi ... And it's prob the gw-monitor.
I was fooled thereIt was my mistake concluding the policy route was working, in the first trace we saw.
A working policy route package would be like the last one you made (google ip)
but with the RasPI MAC instead of the ISP-Router MACSo at the moment pfSense policy routing is NOT working as intended
-
@bingo600 Yes but the rules is matched because it is logged in the pfsense firewall log.
It only is ignoring the gateway in advanced settings....
The same rule in "floating" mode is working... -
This is really strange, now again the floating rule is not working.
I will try to reboot pfsense....
