cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1774
Views
0
Helpful
5
Replies

Cisco port forwarding not working

Marcus Peck
Level 1
Level 1

Dear experts, I got a production firewall (Cisco Pix 515e 6.3(1)) and I have got to configure to allow outside access to a server (SSH only).

The LAN server is 10.0.5.200.

The outside IP address is a.b.c.d. (should I use the FW outside interface IP address?)

Below are the sanitized output:

PIX Version 6.3(1)

interface ethernet0 100full

interface ethernet1 100full

interface ethernet2 auto

interface ethernet3 100full

interface ethernet4 auto shutdown

interface ethernet5 auto shutdown

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 vendor security4

nameif ethernet3 dmz security99

nameif ethernet4 intf4 security8

nameif ethernet5 intf5 security10

enable password XXXXXXXXXXXXXXXX encrypted

passwd XXXXXXXXXXXXXXXXXX encrypted

ip address outside a.b.c.d 255.255.255.240

ip address inside 10.0.1.254 255.255.255.0

ip address vendor X.X.X.X 255.255.255.0

ip address dmz X.X.X.X 255.255.255.0

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 10.0.1.0 255.255.255.0 0 0

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

aaa authentication ssh console LOCAL

ntp server 192.43.244.18 source outside prefer

ntp server 128.102.16.2 source outside

http server enable

PIX Version 6.3(1)

interface ethernet0 100full

interface ethernet1 100full

interface ethernet2 auto

interface ethernet3 100full

interface ethernet4 auto shutdown

interface ethernet5 auto shutdown

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 vendor security4

nameif ethernet3 dmz security99

nameif ethernet4 intf4 security8

nameif ethernet5 intf5 security10

enable password pnxJXWf9kU.x7YfY encrypted

passwd WL6KtWnsAjAQS2yI encrypted

access-list outside_access_in permit ip any any

access-list outside-access-in permit icmp any any

access-list DMZ_access_in permit icmp any any

ip address outside a.b.c.d 255.255.255.240
ip address inside 10.0.1.254 255.255.255.0
ip address vendor X.X.X.X 255.255.255.0
ip address dmz X.X.X.X 255.255.255.0

arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 10.0.1.0 255.255.255.0 0 0

timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
aaa authentication ssh console LOCAL
ntp server 192.43.244.18 source outside prefer
ntp server 128.102.16.2 source outside
http server enable

Those in bold are the commands I added:

static (inside,outside) tcp a.b.c.d 2022 10.0.5.200 ssh netmask 255.255.255.255 0.0

access-list 100 permit tcp any host a.b.c.d eq 2022

access-list 101 permit tcp 10.0.5.200 eq 22 any

access-group 100 in interface ouside

access-group 101 in interface inside

When accessing from the WAN, I used putty to SSH into the IP a.b.c.d port 2022 and it gave me timeouts. I used the:

capture capo interface outside access-group 100

The results were (what i can remember as I am not at the site):

My WAN IP -> a.b.c.d (R)

My WAN IP -> a.b.c.d (S) <nop, nop sackOK>

My WAN IP -> a.b.c.d (S) <nop, nop sackOK>

My WAN IP -> a.b.c.d (S) <nop, nop sackOK>

The server's access from the internal LAN is great and I can access the port 22 on the server from the LAN (note: there is a L3 switch in the environment and the inside IP segments are 10.0.1.0/24 and 10.0.5.0/24 both routable.)

This is what I have done thus far and would like more insights on this issue that I am currently facing. Thank you!

1 Accepted Solution

Accepted Solutions

Hi,

The Static PAT (Port Forward) configuration seemed correct to me.

If you use the interface IP address of "outside" interface then you would usually configure the "interface" parameter rather than the IP address.

static (inside,outside) tcp interface 2022 10.0.5.200 22 netmask 255.255.255.255

Naturally if you can/want to spare a public IP address for this server alone then you could configure Static NAT

static (inside,outside) 10.0.5.200 netmask 255.255.255.255

Which would essentially bind these 2 IP addresses and you could allow the services that are needed to the actual server. Naturally you would also have to allow the traffic in the external ACL to the new public IP address.

But it should work also with your configurations. If you are going to use the interface IP address or a separate public IP address is up to you.

If you are missing the "route" for the subnet 10.0.5.0/24 in your PIX configuration then that is one clear problem in why the server can't be reached from the Internet. So I would start by adding the required "route" and testing it again. If it doesnt work then would be good to check that all the routing between the server and the PIX is fine. For example that there is a route to the server all the way from PIX and the server has a default route taking the traffic to the PIX.

Hope this helps

- Jouni

View solution in original post

5 Replies 5

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

First regarding the configurations you have attempted. It seems to me that according to your above existing firewall configuration you have no ACLs attached yet with the "access-group" command?

If this is true then I would NOT suggest adding the ACL 101 you mention as it only allows traffic that will probably never be matched against it and it will BLOCK ALL of the rest of the traffic essentially stopping all new connections from the LAN. Also you naturally wont need to allow the return traffic of a connection since the firewall is a statefull device and keeps track of the connections formed through it and will allow return traffic through also.

Presuming that you don't have any ACL attached yet to the "outside" interface then this configuration would seem correct

static (inside,outside) tcp a.b.c.d 2022 10.0.5.200 ssh netmask 255.255.255.255 0.0

access-list 100 permit tcp any host a.b.c.d eq 2022


access-group 100 in interface ouside

Its the same configuration you have above.

But the problem in the configuration I see that there is no "route" command for the subnet 10.0.5.0/24 where the host 10.0.5.200 resides.

route inside 10.0.5.0 255.255.255.0 x.x.x.x

Then again I dont even see a default route in your configuration so seems to me that we are looking at a partial configuration. Lacking the route for the LAN network would certain explain SYN Timeouts for the connection.

- Jouni

Hi JouniForss,

     thank you for your reply. I will add the default routes currently in here:

     route outside 0.0.0.0 0.0.0.0 a.b.c.d 1

     Is there any more configurations that I need to append to the firewall besides your suggested route?

Hi,

The Static PAT (Port Forward) configuration seemed correct to me.

If you use the interface IP address of "outside" interface then you would usually configure the "interface" parameter rather than the IP address.

static (inside,outside) tcp interface 2022 10.0.5.200 22 netmask 255.255.255.255

Naturally if you can/want to spare a public IP address for this server alone then you could configure Static NAT

static (inside,outside) 10.0.5.200 netmask 255.255.255.255

Which would essentially bind these 2 IP addresses and you could allow the services that are needed to the actual server. Naturally you would also have to allow the traffic in the external ACL to the new public IP address.

But it should work also with your configurations. If you are going to use the interface IP address or a separate public IP address is up to you.

If you are missing the "route" for the subnet 10.0.5.0/24 in your PIX configuration then that is one clear problem in why the server can't be reached from the Internet. So I would start by adding the required "route" and testing it again. If it doesnt work then would be good to check that all the routing between the server and the PIX is fine. For example that there is a route to the server all the way from PIX and the server has a default route taking the traffic to the PIX.

Hope this helps

- Jouni

Hi Journi,

thank you! I will test this tomorrow again and will update this space. Thank you once again!

Hi Journi, thank you for your help! The missing command is:

route 10.0.5.0 255.255.255.0 a.b.c.d

This enabled static PAT access from the WAN. Thank you so much! It works!

Review Cisco Networking for a $25 gift card