Trying to figure out why redirect host is showing up in my ping

nosenseatall

Here is the full capture. Sorry in advance if it is too much info, but I don't have the knowledge on what to filter and how, so that those of you that are helping only get what you need.

printer_capture_01272021.pcapng

johnpoz

Ok looking at it for 2 seconds.. Can say yeah your sending traffic to your gateway that you shouldn't

You can see the mac of where your sending the data, is not the mac of the .118 box

And that is the mac of your gateway. See where your sending traffic to what is clearly not your network the 143.244 address - its going to your gateway..

Let me comb through it a bit more.. But yeah the redirect is clearly sent - why your sending traffic to 80.1 when your trying to talk to 80.118 which should be on your network..

Can we see the output of your ipconfig to validate mask..

johnpoz

Why do you have traffic going to 1337

https://www.speedguide.net/port.php?port=1337

That wireshark is saying is wireguard? Are you using some a vpn client on this .101 box?

nosenseatall

@johnpoz Yes I am using PIA VPN locally on .101. Also I don't know why what the port 1337 traffic is.

johnpoz

Turn that OFF!!! Bet you your redirects go away..

JKnott

@johnpoz

I also see a redirect, in packet 451, coming from the gateway, which means the original packet is being sent to it. According to the message, the source was 192.168.80.101 and the destination .118. The packet in 450 shows a destination IP of .118, but the MAC shows the gateway. So, that means the sending device thinks the destination is off the local network and so is forwarding packets for it via the gateway.

johnpoz

@nosenseatall said in Trying to figure out why redirect host is showing up in my ping:

Also I don't know why what the port 1337 traffic is.

That is the vpn service using a port that they shouldn't be for that protocol..

https://www.privateinternetaccess.com/helpdesk/kb/articles/understanding-the-wireguard-protocol
A WireGuard connection, therefore, requires connectivity to both TCP 1337 and UDP 1337 on the VPN server.

stephenw10

Yup, looks like they are adding some BS route.

Try running a route print on the Windows client there with the VPN connected and not connected. See what they are actually adding.

VPN providers; discuss....

Steve

nosenseatall

@johnpoz Thank you very much. That fixed the issue. I have no clue why it started malfunctioning. I have used PIA on WireGuard for a while and have not had any problems until recently. At any rate I have uninstalled and will try a fresh install and see if the problem comes back.

Once again thank you for help.

nosenseatall

@johnpoz @JKnott @stephenw10 Thank you all for help. This issue was resolved with @johnpoz suggestion of turning off the VPN.

johnpoz

Well if your all set on using wireguard as the vpn protocol.. 2.5 is coming soon, and should currently work in the snapshots.

You should be able to move the vpn connection to pfsense, and route what you want out the vpn that way..

When your going to use a vpn on some client device on your network, you need to make sure it is setup in such a way to split tunnel correctly. Your local network should just be access normally and only traffic that should go out the vpn is stuff that is not local, be the actual network your on or any other local vlans, etc.

stephenw10

Yup, that ^.

It would be interesting to know what the PIA VPN client was setting though if you're able to get that?

Steve

johnpoz

If I had to "guess" prob something stupid like pointing all rfc1918 routes to the gateway and removing the local route...

I had asked to see the route table had I not ;)

nosenseatall

@johnpoz @stephenw10 I did not get the route table earlier.... my apologies, although I was able to recreate the problem. PIA VPN does allow for split tunneling within the app. I must have inadvertently entered the .118 host IP to bypass the VPN because when I do that, it goes right back into getting stuck like it was originally.

johnpoz

But not sending .118 down the vpn, shouldn't send it to your gateway.. Try splitting the whole local network 192.168.80.0/24

Also when you do that - take a look at the route table

route print

from a cmd line