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

JKnott

This is a time when Wireshark or Packet Capture come in handy, to see what's actually happening on the wire.

stephenw10

Make sure everything has the same subnet mask set. It is behaving as though it's sending those pings to its default gateway which is presumably the 'AP' at 192.168.80.1. Though that must in fact be a router. It should be pinging the printer directly if they are in the same subnet.

Make sure the AP allows direct connections between clients, they often have an option to block that.

Steve

nosenseatall

@jknott I do happen to have a Wireshark capture. I don't have enough experience yet to analyze exactly what it is saying. There is more history to the capture than what I have posted, but here are 2 different spots.
Screen Shot 2021-01-27 at 7.43.31 AM.png

Screen Shot 2021-01-27 at 7.45.46 AM.png

Thank you for your help!

JKnott

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

I do happen to have a Wireshark capture. I don't have enough experience yet to analyze exactly what it is saying. There is more history to the capture than what I have posted, but here are 2 different spots.

Please upload the actual capture. It contains a lot more info than a screen capture.

nosenseatall

@stephenw10 The DHCP server in pfSense for 192.168.80.0 subnet shows 255.255.255.0. The .101 and .118 hosts are on that same subnet.

nosenseatall

@jknott OK I just recaptured the info again, but it will take me a minute to figure out how to filter out all of the other chatter and provide specifics for .101 and .118 hosts.

johnpoz

That redirect screams of mask mismatch..

Or bad arp, or bad routing.. If your client is in the same network, it should never send traffic to 80.1

I take it your client is windows?

Can we see output of ipconfig /all
arp -a after you have pinged 192.168.80.118

And route print output

JKnott

@nosenseatall

With Wireshark, you can filter on IP, MAC or protocol or some combo of those, as needed.

johnpoz

Yeah your not going to want to filter too much, you would need to see the traffic going to 80.1 as the redirect.

Your screenshot don't show any answers at all.

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.