offloading OpenVPN using external gateway
-
@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.... -
@chrispazz said in offloading OpenVPN using external gateway:
This is really strange, now again the floating rule is not working.
I will try to reboot pfsense....Noooooo
Don't say you're using floating rules , i asked about that -
@bingo600
I was NOT using floating rules at all.I tried now to see the same rule in floating mode if it works with raspi gateway or not and with floating IT IS working.....
Why in floating mode use the specified gateway and in normal not floating mode ignores it?
-
This post is deleted! -
It shouldn't
But AFAIK floating rules are always parsed first. -
@bingo600 Should I open a bug in pfsense?
-
@chrispazz
Not yetI think one of the mods / gurus should review this thread first.
@stephenw10 @johnpoz
Any words here -
I don't hope we have been bitten by NAT
The policy rule rule was on a LAN ingress interface , looking at the HOST Source IP of the iMAC. And the Logging showed a match.Technically the source IP is later being set to the pfSense WAN IP, but the new gateway ought to have been set before that.
I'm officialy confused
I do hope your policy rule was the top most rule , and that you didn't have any rules before that on that interface , else we'we been chasing ghosts all night.
A permit ICMP any any before the policy rule would have made that "ghost"
/Bingo
-
@bingo600 eheheh
Yes, the policy rule is the first one on that interface.
-
I tried some other tests but no luck. I am officially unable to apply that gateway
