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

    Unable to telnet from LAN to WAN subnet

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 4 Posters 5.3k Views
    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.
    • P
      PistolPete
      last edited by

      Hi All,

      I have the following setup:

      WEB <-> Router <-> pfSense <-> LAN

      I've got a single public IP public on the WAN of the router.  I've got a /30 inbetween the router LAN and firewall WAN and a /27 on the LAN.  I also have a /29 on the OPT1 port as a DMZ.
      The router is configure as basically a modem that routes (wireless, NAT, firewall etc etc is all disabled) and everything is running fine and has been for many months.

      Today I came across as issue trying to telnet onto the router from the LAN in that it was failing to connect.  I checked the router (can HTTP onto it fine) and Telnet is running so I SSH onto the pfSense box and I can telnet into the router from there fine.  I checked and I can telnet onto a box on the web fine (telnet://towel.blinkenlights.nl if you like Star Wars  :D ) so I'm a little stumped.

      I ran Wireshark and it appears that the PC and the router are talking - kinda - but the data appears to be getting corrupted or something via pfSense.
      I temporarily connected my PC directly to the router taking the pfSense WAN IP and I could telnet in fine.

      Anyone throw any light onto this??

      Pete

      1 Reply Last reply Reply Quote 0
      • marcellocM
        marcelloc
        last edited by

        Can you check if traffic from lan to modem is being natted by pfsense?

        If lan machine has a firewall lan rule and nat on firewall to Allow Telnet it should work.

        Treinamentos de Elite: http://sys-squad.com

        Help a community developer! ;D

        1 Reply Last reply Reply Quote 0
        • P
          PistolPete
          last edited by

          There is no NAT running, it's straight routing.
          All my IP ranges (Router WAN /32, Firewall Interlink /30, LAN /27 & DMZ /29) are all public ranges.

          I have an allow all out set on the LAN and DMZ to try and diagnose the problem, and I've set an allow telnet in from the router to the LAN & DMZ subnet just to check but no dice.
          As I say, they are communicating to the extent that packets travelling between the machines so I'm 100% sure it's not a routing issue (as I can HTTP onto the router) and 99% sure it's not a firewall ACL issue.

          1 Reply Last reply Reply Quote 0
          • P
            PistolPete
            last edited by

            Anyone got any clues?  I have a wireshark capture of the Telnet and HTTP sessions if that's any use to you.

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              packet capture of the telnet could be telling.

              1 Reply Last reply Reply Quote 0
              • P
                PistolPete
                last edited by

                http://www.the-crib.co.uk/telnet.pcap

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

                  The TCP handshake completes, and then the 81.187.x.x host immediately sends a FIN ACK, telling the source of the TCP connection that it's killing the connection. Why, hard to say, not sure what IP is associated with what, but that's the problem. Firewall wouldn't be related to that, it'll never send a FIN ACK.

                  1 Reply Last reply Reply Quote 0
                  • P
                    PistolPete
                    last edited by

                    81.x is the LAN interface on the router, 90.x is the WAN interface on the pfSense.

                    If I SSH into pfSense and then telnet out, it works - http://www.the-crib.co.uk/telnetfrompfsense.cap
                    Also, if I pull pfSense and put my PC direct to the router and use the pfSense WAN IP address, it also works.

                    It only ever fails THROUGH pfSense.

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

                      In both the above working cases the machine initiating the telnet session is within the subnet of the router LAN interface. If you try to do the same from the other side of your pfSense box presumably the traffic has to be routed. Though it's hard to say from your description of your subnets.
                      My initial thought on this was that the router didn't have a route back to your client PC but that cannot be the case since the initial TCP handshake completes.
                      Therefore perhaps your router has a restriction on allowing telnet only from within it's own subnet?

                      Steve

                      1 Reply Last reply Reply Quote 0
                      • P
                        PistolPete
                        last edited by

                        I never thought about there being a restriction on the telnet daemon not talking to outside it's subnet.

                        Might need to contact Billion and see.

                        1 Reply Last reply Reply Quote 0
                        • C
                          cmb
                          last edited by

                          It's a screwy way to block a connection, but that device is without question blocking the connection, it has nothing to do with your firewall. Off-subnet access being rejected is the most likely cause.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.