• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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.5k 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 Feb 14, 2012, 11:14 PM

    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
    • M
      marcelloc
      last edited by Feb 15, 2012, 2:41 AM

      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 Feb 15, 2012, 7:29 AM

        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 Feb 16, 2012, 2:40 PM

          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 Feb 18, 2012, 7:23 AM

            packet capture of the telnet could be telling.

            1 Reply Last reply Reply Quote 0
            • P
              PistolPete
              last edited by Feb 18, 2012, 1:28 PM

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

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by Feb 19, 2012, 1:57 AM

                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 Feb 19, 2012, 12:50 PM

                  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
                  • S
                    stephenw10 Netgate Administrator
                    last edited by Feb 19, 2012, 1:20 PM

                    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 Feb 19, 2012, 4:10 PM

                      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 Feb 20, 2012, 1:17 AM

                        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
                        11 out of 11
                        • First post
                          11/11
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                          This community forum collects and processes your personal information.
                          consent.not_received