Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

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

    General pfSense Questions
    4
    25
    100
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      nosenseatall last edited by nosenseatall

      I've been trying to diagnose a printer problem over the last couple of days and still can't figure out what is going on. When I send something to the printer it starts by printing a couple of lines and then stops. There is a message on the screen "receiving data" but it never finishes the print job. It only happens from one specific host all other host can send and print normally with no issues.

      My printer is wireless and connected to the AP with an address of 192.168.80.118. My computer is connected to the AP with an address of 192.168.80.101. As I was trying to solve the problem I ran some pings. When I ping any host other than the printer I get normal looking return Screen Shot 2021-01-26 at 9.04.57 PM.png

      Screen Shot 2021-01-26 at 9.05.15 PM.png

      but when I ping the printer at .118 it looks different with some verbiage about "Redirect Host".
      Screen Shot 2021-01-26 at 9.05.44 PM.png

      Is it possible that this redirect has something to do with why the print jobs are failing from host at .101? At one point I was trying to solve a different issue and set my computer to a static ip address (DHCP with manual address) and not sure if when I changed it back to just DHCP caused the problem.

      The AP is pulling its IP address from pfSense, which has its own interface assignment at em4. I also logged in to AP and didn't see anything abnormal since it is in AP mode.

      Any suggestions or help would be great as I can't print anything at the moment.

      JKnott 1 Reply Last reply Reply Quote 0
      • JKnott
        JKnott @nosenseatall last edited by

        @nosenseatall

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

        N 1 Reply Last reply Reply Quote 0
        • stephenw10
          stephenw10 Netgate Administrator last edited by

          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

          N 1 Reply Last reply Reply Quote 0
          • N
            nosenseatall @JKnott last edited by

            @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!

            1 Reply Last reply Reply Quote 0
            • JKnott
              JKnott last edited by

              @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.

              N 1 Reply Last reply Reply Quote 0
              • N
                nosenseatall @stephenw10 last edited by

                @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.

                johnpoz 1 Reply Last reply Reply Quote 0
                • N
                  nosenseatall @JKnott last edited by

                  @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.

                  JKnott 1 Reply Last reply Reply Quote 0
                  • johnpoz
                    johnpoz LAYER 8 Global Moderator @nosenseatall last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • JKnott
                      JKnott @nosenseatall last edited by

                      @nosenseatall

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

                      johnpoz 1 Reply Last reply Reply Quote 0
                      • johnpoz
                        johnpoz LAYER 8 Global Moderator @JKnott last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • N
                          nosenseatall last edited by

                          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 1 Reply Last reply Reply Quote 0
                          • johnpoz
                            johnpoz LAYER 8 Global Moderator @nosenseatall last edited by

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

                            macaddress.png

                            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 JKnott 2 Replies Last reply Reply Quote 0
                            • johnpoz
                              johnpoz LAYER 8 Global Moderator @johnpoz last edited by 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?

                              wireguard.png

                              N 1 Reply Last reply Reply Quote 0
                              • N
                                nosenseatall @johnpoz last edited by nosenseatall

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

                                johnpoz 2 Replies Last reply Reply Quote 0
                                • johnpoz
                                  johnpoz LAYER 8 Global Moderator @nosenseatall last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • JKnott
                                    JKnott @johnpoz last edited by

                                    @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.

                                    1 Reply Last reply Reply Quote 0
                                    • johnpoz
                                      johnpoz LAYER 8 Global Moderator @nosenseatall last edited by

                                      @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.

                                      N 1 Reply Last reply Reply Quote 0
                                      • stephenw10
                                        stephenw10 Netgate Administrator last edited by

                                        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

                                        1 Reply Last reply Reply Quote 0
                                        • N
                                          nosenseatall @johnpoz last edited by 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.

                                          1 Reply Last reply Reply Quote 0
                                          • N
                                            nosenseatall last edited by nosenseatall

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

                                            johnpoz 1 Reply Last reply Reply Quote 0
                                            • johnpoz
                                              johnpoz LAYER 8 Global Moderator @nosenseatall last edited by 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.

                                              1 Reply Last reply Reply Quote 1
                                              • stephenw10
                                                stephenw10 Netgate Administrator last edited by

                                                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 1 Reply Last reply Reply Quote 0
                                                • johnpoz
                                                  johnpoz LAYER 8 Global Moderator @stephenw10 last edited by

                                                  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 ;)

                                                  N 1 Reply Last reply Reply Quote 0
                                                  • N
                                                    nosenseatall @johnpoz last edited by

                                                    @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 1 Reply Last reply Reply Quote 0
                                                    • johnpoz
                                                      johnpoz LAYER 8 Global Moderator @nosenseatall last edited by 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

                                                      1 Reply Last reply Reply Quote 0
                                                      • First post
                                                        Last post

                                                      Products

                                                      • Platform Overview
                                                      • TNSR
                                                      • pfSense Plus
                                                      • Appliances

                                                      Services

                                                      • Training
                                                      • Professional Services

                                                      Support

                                                      • Subscription Plans
                                                      • Contact Support
                                                      • Product Lifecycle
                                                      • Documentation

                                                      News

                                                      • Media Coverage
                                                      • Press
                                                      • Events

                                                      Resources

                                                      • Blog
                                                      • FAQ
                                                      • Find a Partner
                                                      • Resource Library
                                                      • Security Information

                                                      Company

                                                      • About Us
                                                      • Careers
                                                      • Partners
                                                      • Contact Us
                                                      • Legal
                                                      Our Mission

                                                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                      Subscribe to our Newsletter

                                                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                      © 2021 Rubicon Communications, LLC | Privacy Policy