cannot access Bitvise server on port 22 from 871W

[thunderbirdx336]

I am pretty new to Cisco gear and a newbie at ACLs but here goes...

here is the ouput from  #sh ip access-lists

Standard IP access list 1

    10 permit 192.168.1.0, wildcard bits 0.0.0.255 (1993 matches)

Extended IP access list FILTERNET

    10 permit tcp 111.222.333.0 0.0.0.255 host 192.168.1.42 eq 22

    20 permit tcp 192.168.1.0 0.0.0.255 any eq www

    30 permit tcp any host 222.333.444.555 eq www (135 matches)

    40 permit tcp 111.222.333.0 0.0.0.255 any eq telnet (2964 matches)

    50 permit tcp 222.333.444.555 0.0.0.7 any eq telnet (5328 matches)

    60 permit tcp any any established (125628 matches)

    70 permit udp any any (2833 matches)

    80 deny ip any any (258 matches)

access list 1 is of course for nat... and all of the clients can access the WAN just fine

FILTERNET is intended to, among other things, forward port 22 traffic from 111.222.333.0 0.0.0.255 to 192.168.1.42 where Bitvise is running and listening on port 22. This is a applied to FastEthernet4 as: ip access-group FILTERNET in

I have 8 static public IP addresses and this works fine with my Linksys WRT54G when he's running the show, so I know that the setup in Bitvise is solid...

I can telnet in from 111.222.333.xxx and 222.333.444.xxx just fine but I cannot connect to Bitvise; what puzzles me is the show ip access-lists does not show any packets allowed in on port 22 and the 80 deny any any is counting up each time I try to log in so I can only assume it is denying port 22. However, from Line 40 I see that same outside address is successful in bringing telnet traffic in.

I have ssh on the vty lines shut off right now on the 871W, by the way. Also, I can choose a different port for Bitvise to listen on and can log in from that port if that would cure it, I didn't think about that until just now... does the router block port 22 no matter how the ACL is set if ssh is shut off on the vty lines?

Thanks in advance,

-Gary

[Jouni Forss]

Hi,

The "access-group" command and the related "access-list" wont do any type of NAT alone. You will use those to allow traffic to the public NAT IP address which you have chosen for the server on the LAN

You will either use Static NAT to give the local IP address the public IP address

ip nat inside source static

Or you will use Static PAT to forward a single port only to the server on the LAN

ip nat inside source static tcp

Or did you have these NAT configurations done?

Also naturally in the ACL you will have the destination IP address set as the NAT IP address and not the local real IP address.

EDIT: Typos in the NAT commands

- Jouni

[thunderbirdx336]

Yes, the NAT config works fine, that is what I meant by

access list 1 is of course for nat... and all of the clients can access the WAN just fine

I just can't get in on port 22, at least not to the Bitvise server, but I can telnet in... and I can get in on port 80 to the http server... and SDM can access the router too...

[Jouni Forss]

Hi,

I would presume the ACL 1 defines the source address/subnet for Dynamic PAT translation towards Internet? Cant see the actual NAT configuration that uses the ACL. The ACL alone wont do anything.

For traffic that is coming from the Internet towards your LAN the basic Dynamic PAT wont enable any traffic to pass.

To give a public IP address to a single LAN host you will need to use Static NAT or Static PAT that is shown above.

Then you will need to allow the traffic to the public IP address that is used in the NAT configuration and have that ACL attached to the interface of the router that is connected to the Internet.

- Jouni

[thunderbirdx336]

I remember reading about this now that I read your post again...

I put in this command:

ip nat inside source static tcp extended

but have now lost contact with the router, perhaps the "extended" option messed it up? I'll have to go in through the console port when I get home and try to fix it.

Thanks Jouni,

-Gary

[Jouni Forss]

Hi,

If I have understood you correctly, you have a

• A device on your LAN that you want to access through the Internet
• This device needs to be accessed through the port TCP/22
• You have several public IP address at your disposal

In that case you should probably take one of the public IP addresses that is not in use and configure Static NAT for it. Then you should allow the traffic you need on the ACL that is attached to the WAN port of the router.

If you truly lost the management connection to the router then I would presume it means that you did Static PAT for port TCP/22 using the public IP address that is configured to the WAN interface of the router. This might mean that any SSH management connection aimed at the WAN IP address of the router might now get forwarded to the LAN and therefore you wont be able to initiate a remote management connection.

Unless you have some other form of management enabled like Telnet or Web based management.

- Jouni

[thunderbirdx336]

In that case you should probably take one of the public IP addresses that is not in use and configure Static NAT for it. Then you should allow the traffic you need on the ACL that is attached to the WAN port of the router.

yes, that is what I did, I left the address alone that is assigned to Fa4 ( the WAN port on the router) and assigned a spare to the static nat... not sure why the Telnet dropped out yet...

ha! that's odd... it's back up, something I did must've caused a reboot... since I didn't save the config, the static nat is gone, I will try it again, this time w/o the "extended" option and see what happens...

[thunderbirdx336]

OK, I got it sorted out, it wasn't as much a problem with NAT as it was with my ACL...

ip nat inside source list 1 interface FastEthernet4 overload

ip nat inside source static tcp 192.168.1.42 22 interface FastEthernet4 22   <-- using ONLY port 22 of the outside address

!

ip access-list extended FILTERNET

permit tcp any any eq 22                                           <-- opened this up; letting the static nat handle this port

permit tcp xxx.xxx.xxx.xxx 0.0.0.255 any eq telnet      <-- an external subnet that I trust

permit tcp xxx.xxx.xxx.xxx 0.0.0.7 any eq telnet         <-- another trusted subnet

permit tcp any any established                                   <-- only connections that I initiate are allowed

permit icmp any any                                                  <-- for now, allowing pings

permit udp any any                                                    <- some things just would not work w/o this

deny   ip any any                                                      <-- implied, I know, but this way I can see the count

!

access-list 1 permit 192.168.1.0 0.0.0.255

works like a champ now! Thanks for the help!!