Cisco IOS: Reverse NAT public -> Private setup

You need to configure an "outside local" NAT.

Sorry, busy in class.  

OK, so am I way off on this command?

ip nat outside source static 12.28.199.103 10.1.1.100

Phil

OK, reversed the two IPs:

ip nat outside source static 10.1.1.100 12.28.199.103

I have a PING reply now on the public IP, but still no dice on traffic passing. What did I miss?

Phil

Yes, sure am. 12.28.199.103 is on the outside, and the 10.1.1.100 is on the inside.

I tried as you suggested. I can ping the outside IP again, but network connectivity does not seem to exist still.

Any other suggestions?

Phil

Do you have an access-list that is preventing communication?

Yes / no : I do have an access list, but its for the regular NAT (inside -> outside)

p nat pool office 12.28.199.10 12.28.199.10 netmask 255.255.255.252
ip nat inside source list 1 pool office overload

access-list 1 permit 10.1.2.0 0.0.0.255
access-list 1 permit 10.1.1.0 0.0.0.255

Since I am not specifying the use of this access-list with the above command it should not interfere, right?

Try denying that host

access-list 1 deny 10.1.1.100

No change. IP is pingable again, but no traffic passes on the public IP. (I can access the web server on the private IP, but not the public).

Phil

Can you post your whole config?

version 12.1
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname cyberweb-rtr1
!
<removed paswd>
!
!
!
!
!
clock timezone Eastern -5
ip subnet-zero
ip cef
ip name-server 12.127.16.67
ip name-server 12.127.17.71
ip dhcp excluded-address 10.1.1.100 10.1.1.110
ip dhcp excluded-address 10.1.1.2
ip dhcp excluded-address 10.1.1.1
!
ip dhcp pool office
   network 10.1.1.0 255.255.255.0
   default-router 10.1.1.1
   dns-server 12.28.199.104 12.28.199.108
   domain-name cyberwebhosting.net
   lease 7
!
!
controller T1 0/0/0
 channel-group 0 timeslots 1-24
 description AT&T T1 #1
!
controller T1 0/0/1
!
controller T1 0/0/2
!        
controller T1 0/0/3
!
!
!
interface Serial0/0/0:0
 ip address 12.125.190.190 255.255.255.252
 ip nat outside
 encapsulation ppp
 autodetect encapsulation ppp
 fair-queue
!
interface FastEthernet0/1/0
 description Copper - 100TX PublicLAN to NetScreen
 ip address 12.28.199.1 255.255.255.0
 ip nat outside
 half-duplex
!
interface FastEthernet4/0/0
 description Fiber - Unused
 no ip address
 full-duplex
!
interface FastEthernet4/1/0
 description Fiber - CorpLAN to Cisco 2924XL Switch
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
 full-duplex
!
ip nat pool office 12.28.199.10 12.28.199.10 netmask 255.255.255.252
ip nat inside source list 1 pool office overload
ip nat inside source static 10.1.1.100 12.28.199.103
ip classless
ip route 0.0.0.0 0.0.0.0 12.125.190.189
ip route 10.1.2.0 255.255.255.0 10.1.1.2
no ip http server
!
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 1 permit 10.1.2.0 0.0.0.255
snmp-server community public RO
banner login ^CCCyberWEB Networks Inc.^C
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 exec-timeout 0 0
 login
!
ntp clock-period 17179880
ntp server 66.187.233.4
scheduler process-watchdog hang
end

What is the default gateway of the server? Is it 10.1.1.1 ?

If this is your outside interface, is there a Netscreen firewall that is preventing the web access inbound?
>
interface FastEthernet0/1/0
 description Copper - 100TX PublicLAN to NetScreen
 ip address 12.28.199.1 255.255.255.0
>

Default gateway on the NAT is 10.1.1.1 (which is the Cisco router). So server is 10.1.1.100 <-> 10.1.1.1 <-> 12.28.199.103 (router IP for NAT)

Netscreen is bridged between the 12.28.199.1 GW and the 12.28.199.x subnet - so, firewall does not handle traffic on the NAT side.

So router has 3 interfaces:

1- NAT
2- Public LAN
3- WAN

Netscreen is on #2. Traffic (for this problem) flows between #1 and #3.

Phil

You still need to deny that host from using the PAT address:

access-list 1 deny 10.1.1.100 0.0.0.0
Then clear xlates...
clear ip nat trans *

Can that server browse the internet OK?

Try unplugging the Fa 0/1/0 interface to the Netscreen. I'm thinking proxy arp poisoning by the netscreen...

Yes! That worked great. I forgot to clear the NAT xlations after making the access-list change.

May I ask 1 more question regarding this?

How can I further enhance the reverse NAT to deny certain ports (namely netbios, 137-139, etc). Or is this beyond the scope of what can be done at the router level?

Phil

You should have an inbound access-list that only permits specific ports....

i.e.

access-list extended inbound
 permit tcp any any established
 permit udp any eq 53 any
 permit tcp any host 12.28.199.103 eq 80
 deny udp any any eq 137
 deny udp any any eq 138
 deny tcp any any eq 139
 deny tcp any any e1 135
<etc...>
 deny ip any any log  <-- log keyword will help troubleshoot and refine the acl

Interface Serial 0/0/0:0
 ip access-group inbound in
!

It does not seem to work. I created an access-list as such:

access-list 100 remark Used for inbound traffic for reverse NAT
access-list 100 permit tcp any any established
access-list 100 permit tcp any host 12.28.199.103 eq www
access-list 100 permit tcp any host 12.28.199.103 eq 8191
access-list 100 permit tcp any host 12.28.199.103 eq 8192
access-list 100 permit udp any host 12.28.199.103 eq 8191
access-list 100 permit udp any host 12.28.199.103 eq 8192
access-list 100 deny   tcp any any eq 135
access-list 100 deny   udp any any eq netbios-ns
access-list 100 deny   udp any any eq netbios-dgm
access-list 100 deny   tcp any any eq 139
access-list 100 deny   ip any any log

Then added the access-group to the NAT interface since the traffic flows "inbound" to the server over this interface.

interface FastEthernet4/1/0
 description Fiber - CorpLAN to Cisco 2924XL Switch
 ip address 10.1.1.1 255.255.255.0
 ip access-group 100 in
 ip nat inside
 full-duplex
!

After doing this, I was still able to establish a NetBIOS connection.

Phil

You applied it to the wrong interfce..
Apply it "in" to the Serial interface as in my example

You are trying to block outsiders (public) from connecting, no?
You are not trying to block insiders (10.1.x.x) from connecting, are you? You can't do that with access-list on the router because users and server are on the same physical interface..

When deciding where to place an access-list, think of it as a physical door.
You have an inside door and an outside door with a breezeway in between.
Do you want to keep anyone from coming "in" the outside door uninvited?  Wan interface "in"
Do you want to let them come in the outer door into the breezeway, but not get to the inside?  Lan interface "out"
Do you want to let them come in the outer door, into the LAN, but not go back out from the LAN? Lan interface "in"
Do you just want to block from LAN to outside? Lan interface "in"
You can use combinations with different acls applied to different interfaces...

OK - I understand. But, by doing this I need to make sure I dont interfere with any traffic coming in on the WAN interface UNLESS its for 12.28.199.103. So, I should adjust the access-list to.... ? I need to say "allow everything, except when going to 12.28.199.103" - since the netscreen does are firewalling otherwise.

Does this statement say allow all?
access-list 100 permit tcp any any established

If so, and I then add some denys, do the denys override the allow all statement?

Not sure where to go here. I am a bit nervous if I apply something wrong to the WAN interface and block traffic.

Ive been doing some reading, I think this will work and do exactly what I want. Need a 2nd opinion:

access-list 100 permit tcp any host 12.28.199.103 eq 80
access-list 100 permit tcp any host 12.28.199.103 eq 8191
access-list 100 permit tcp any host 12.28.199.103 eq 8192
access-list 100 permit udp any host 12.28.199.103 eq 8191
access-list 100 permit udp any host 12.28.199.103 eq 8192
access-list 100 deny ip any host 12.28.199.103 log
access-list 100 permit ip any any

So, allow 80,8191,8192 to 12.28.199.103, then deny everything else to 12.28.199.103, then last - allow all traffic elsewhere ??

My final inbound access list would read:

access-list 100 deny   ip 192.168.0.0 0.0.255.255 any
access-list 100 deny   ip 172.16.0.0 0.15.255.255 any
access-list 100 deny   ip 10.0.0.0 0.255.255.255 any
access-list 100 deny   ip 127.0.0.0 0.255.255.255 any
access-list 100 deny   ip 255.0.0.0 0.255.255.255 any
access-list 100 deny   ip 224.0.0.0 7.255.255.255 any
access-list 100 deny   ip host 0.0.0.0 any
access-list 100 deny   ip 12.28.199.0 0.255.255.255 any

access-list 100 permit tcp any host 12.28.199.103 eq 80
access-list 100 permit tcp any host 12.28.199.103 eq 8191
access-list 100 permit tcp any host 12.28.199.103 eq 8192
access-list 100 permit udp any host 12.28.199.103 eq 8191
access-list 100 permit udp any host 12.28.199.103 eq 8192
access-list 100 deny ip any host 12.28.199.103 log

access-list 100 permit ip any any

My access-list is much simpler and streamlined. You've been reading the well-intentioned, but mis-aligned suggestions elsewhere to block all private and internal access.

Let me explain my acl:
I use named extended acl, but numbered is same affect

access-list extended inbound  <-- names the extended acl
 permit tcp any any established  <-- permit all return traffic from inside requests, ie. web server responses
 permit udp any eq 53 any <-- permit dns querry responses
 permit tcp any host 12.28.199.103 eq 80  <-- permit inbound traffic
 permit tcp any host 12.28.199.103 eq 8191 <--
 permit tcp any host 12.28.199.103 eq 8192  <--
 permit udp any host 12.28.199.103 eq 8191  <--
 permit udp any host 12.28.199.103 eq 8192  <--
 #deny ip any host 12.28.199.103           <-- no need for this deny statement, deny all at the end catches it
 deny udp any any eq 137 <-- deny ALL inbound netbios
 deny udp any any eq 138 <-- Yes, it is covered by deny all at the end, but will keep
 deny tcp any any eq 139  <-- this traffic out of your log
 deny tcp any any eq 135  <--

 deny ip any any log  <-- log keyword will help troubleshoot and refine the acl

The final deny all replaces your multiple lines above

Apply it "in" on your WAN interface and life will be good.
Keep an eye on your logs and you can refine it as you go..

By doing what you have stated above, however, I will be blocking the rest of the "good" traffic to the remainder of the subnet. 12.28.199.103 is 1 host out of dozens that the netscreen handles. Since I have said only to allow certain traffic and deny the rest, I would basically need to recreate what my netscreen does.

My approach was to only firewall the NAT traffic and allow the rest to pass via the existing firewall as normal.

Am I making sense?

Phil

Seems to be a slippery slope we're on.
You can add a "permit tcp any 12.28.199.0 0.0.0.255"
just before the deny line

Exactly what I did, all works perfect!

Thanks so much for your help!

Phil