Configuration for telnet access to inside host via PIX

[PNI-ITRNP]

I am trying to allow telnet access to a host on the inside that has an external internet address assigned to it via a PIX Firewall. In addition to port 23 (telnet), I have other ports opened for that host, such as 80, and 443. Access to that host via the other ports (80, 443) works fine. However, if we attempt access to the host using telnet (even though the acl permits it) it does not work.

I know it is just a configuration thing on the PIX, but I cannot figure it out. Has anyone had this issue in the past, and what steps or configuration parameters were used to make such access work from the outside in via port 23.

Just to clarify, I don't need access to the outside PIX interface on port 23, I need access to an internal host from the outside through the PIX via port 23.

[Julio Carvajal]

Hello,

You should need only an ACL and of course the port-forwarding.

Can you share that config?

[PNI-ITRNP]

That is what I figured as well, at a very minimal here is what I have in the config (using bogus IPs):

static (inside,outside) 192.168.1.14 10.0.16.32 netmask 255.255.255.255

access-list outside_access_in extended permit tcp any 192.168.1.14 eq telnet

Like I mentioned I also have port 80, and 443 open. When I watch the logs I can see traffic hit the rules for 80, and 443, but when I attempt telnet I never see the traffic.

[Julio Carvajal]

So you are trying to telnet 192.168.1.14

Looks like a server issue, does it work locally?

Time for a capture

access-list capture_in permit tcp any host 10.0.16.32 eq 23

access-list capture_in permit tcp host 10.0.16.32 eq 23 any

access-list capture_out permit tcp any host 192.168.1.14 eq 23

access-list capture_out permit tcp host 192.168.1.14 eq 23 any

capture out access-list capture_out interface outside

capture in access_list capture_in interface inside

Then try to connect, and let me know the following:

show cap out

show cap in

[PNI-ITRNP]

Yes, and I can telnet the internal host 10.0.16.32 with no issue from another client on the same network.

The only access that fails is from the outside in.

I'll try what you suggested.

[PNI-ITRNP]

OK, I only did the "out" capture, but it did not capture any traffic coming from outside in destined for port 23?

Result of the command: "sho cap out"

0 packet captured
0 packet shown

Almost like access for port 23 is denied somewhere?

[Julio Carvajal · Accepted solution]

Hello,

But that would be somewhere else ( not the pix) as he is not receiveing the traffic,

Do check that please,

Regards

[PNI-ITRNP]

To verify that command worked for the capture, I changed the the acl to this:

access-list capture_out permit tcp any host 192.168.1.14 access-group Web_Services

Web_Services group includes ports 80, 443, and the one I am trying to get to work 23.

Here is the "sho cap out" results now (I only grabbed ten lines, 599 is too many - ):

599 packets captured

   1: 16:35:40.754096 67.52.2.30.58245 > 192.168.1.14.443: P 2709611153:2709611867(714) ack 39303471 win 16545

   2: 16:35:40.917570 67.52.2.30.58245 > 192.168.1.14.443: . ack 39303817 win 16458

   3: 16:35:40.921339 67.52.2.30.58245 > 192.168.1.14.443: . ack 39303891 win 16440

   4: 16:35:40.921384 67.52.2.30.58245 > 192.168.1.14.443: . ack 39306651 win 16560

   5: 16:35:40.925275 67.52.2.30.58245 > 192.168.1.14.443: . ack 39309411 win 16560

   6: 16:35:40.925306 67.52.2.30.58245 > 192.168.1.14.443: . ack 39311400 win 16560

   7: 16:35:40.925367 67.52.2.30.58245 > 192.168.1.14.443: . ack 39311474 win 16541

   8: 16:35:41.000030 67.52.2.30.58245 > 192.168.1.14.443: P 2709611867:2709612389(522) ack 39311474 win 16541

   9: 16:35:41.003616 67.52.2.30.27127 > 192.168.1.14.443: P 2315499843:2315500365(522) ack 962852862 win 16464

  10: 16:35:41.093241 67.52.2.30.58245 > 192.168.1.14.443: . ack 39311820 win 16455 599 packets captured
   1: 16:35:40.754096 67.52.2.30.58245 > 192.168.1.14.443: P 2709611153:2709611867(714) ack 39303471 win 16545
   2: 16:35:40.917570 67.52.2.30.58245 > 192.168.1.14.443: . ack 39303817 win 16458
   3: 16:35:40.921339 67.52.2.30.58245 > 192.168.1.14.443: . ack 39303891 win 16440
   4: 16:35:40.921384 67.52.2.30.58245 > 192.168.1.14.443: . ack 39306651 win 16560
   5: 16:35:40.925275 67.52.2.30.58245 > 192.168.1.14.443: . ack 39309411 win 16560
   6: 16:35:40.925306 67.52.2.30.58245 > 192.168.1.14.443: . ack 39311400 win 16560
   7: 16:35:40.925367 67.52.2.30.58245 > 192.168.1.14.443: . ack 39311474 win 16541
   8: 16:35:41.000030 67.52.2.30.58245 > 192.168.1.14.443: P 2709611867:2709612389(522) ack 39311474 win 16541
   9: 16:35:41.003616 67.52.2.30.27127 > 192.168.1.14.443: P 2315499843:2315500365(522) ack 962852862 win 16464
  10: 16:35:41.093241 67.52.2.30.58245 > 192.168.1.14.443: . ack 39311820 win 16455

We can tell the rules work, and even the capture rule is working, but not sure why it does not show any attempts over port 23.

[Julio Carvajal · Accepted solution]

Hello,

Yeah, but what you have to notice here is the PIX is not receiving that traffic.

So what should you do now:

1) Make sure the telnet client is sending the traffic out ( Wireshark)

2) Check the path between telnet client-server and check for ACL's,routes,etc.

On the PIX side we are all good!

Regards,

Remember to rate all of the helpful post (If you do not know how to rate a post, just let me know, I will let you know how)

Julio

[PNI-ITRNP]

Sounds good. I am going to check on everything, see if I can figure out why the traffic is not getting to the PIX and once figured out post what the resolution is. Thanks for the help.

[Julio Carvajal]

Hello,

Sure, let us know

Remember to rate all of the helpful post (If you do not know how to rate a post, just let me know, I will let you know how)

Julio

[PNI-ITRNP]

OK, so I figured out my issue. For all those wondering what the PIX configuration should be, I had it correct, so no problems there.

My Network administrator failed to inform me that because of a security audit he filtered out several ports from ever reaching our firewall interface, those ports include port 23 (telnet).

The fix for us is to use Citrix to publish the desired client and allow acces to that particular device only over the inside network. Using Citrix we pubished the client the user needed, and then provided access to that published application via our Citrix Web Interface solution.

Everyone is happy!