Unable to telnet from LAN to WAN subnet
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??
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.
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.
Anyone got any clues? I have a wireshark capture of the Telnet and HTTP sessions if that's any use to you.
packet capture of the telnet could be telling.
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.
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.
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?
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.
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.