Port forwarding stopped working when I added DHCP to my public interface. Help?

[crazyman143]

Hi folks. So I'm using an 1841 router connected to cable modem ISP for small network. FA0/0 recieves ip address via DHCP from the modem. I need to forward ports 80,443,500,4500 for incoming connections to my vpn server. problem is it's not working. here's relevant config:

interface FastEthernet0/0
 ip address dhcp
 ip access-group Firewall in
 ip inspect Firewall-SPI out
 ip nat outside
 no cdp enable
 no shutdown
 
interface FastEthernet0/1.1
 encapsulation dot1Q 1 native
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
 no cdp enable
 
ip nat inside source list NATRULE interface FastEthernet0/0 overload
 
ip nat inside source static tcp 10.1.1.2 80 interface FastEthernet0/0 80
ip nat inside source static tcp 10.1.1.2 443 interface FastEthernet0/0 443
ip nat inside source static udp 10.1.1.2 500 interface FastEthernet0/0 500
ip nat inside source static udp 10.1.1.2 4500 interface FastEthernet0/0 4500

ip access-list extended Firewall
 permit tcp any any eq 80
 permit tcp any any eq 443
 permit udp any any eq 500
 permit udp any any eq 4500
 permit udp any any eq bootps
 permit udp any any eq bootpc
 
ip access-list extended NATRULE
 permit ip 10.1.0.0 0.0.255.255 any
 permit ip 192.168.254.0 0.0.0.255 any
 deny   ip any any

This doesn't work and the ports do not seem to be open. Now, before we got the cable modem, I had a double nat setup with the old DSL modem. I had a private IP set statically on FA0/0, and this worked. It was setup similar with these differences:

interface FastEthernet0/0
 ip address 192.168.0.2 255.255.255.0
 ip access-group Firewall in
 ip inspect Firewall-SPI out
 ip nat outside
 
 interface FastEthernet0/1.1
 encapsulation dot1Q 1 native
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
 no cdp enable
 
ip nat inside source list NATRULE interface FastEthernet0/0 overload
ip nat inside source static tcp 10.1.1.2 80 192.168.0.2 80 extendable
ip nat inside source static tcp 10.1.1.2 443 192.168.0.2 443 extendable
ip nat inside source static udp 10.1.1.2 500 192.168.0.2 500 extendable
ip nat inside source static udp 10.1.1.2 4500 192.168.0.2 4500 extendable
ip route 0.0.0.0 0.0.0.0 192.168.0.1

ip access-list extended Firewall
 permit ip any any

Now, I am baffled as to why it isn't working the new way with DHCP. Even changing "Firewall" ACL to permit any any it doesn't work. Somewhere i found a command that would forward ALL incoming ports to the host, that worked but isn't safe and not a solution. I really don't want to switch back to double nat or pay for a static IP on the outside interface. What can I do to get the ports to forward to 10.1.1.2? Thanks for your time.

[m.kafka]

Hi crazyman (peculiar nick BTW),

The IOS NAT configuration guide suggests:

The first packet that the router receives from host 10.1.1.1 causes the 
router to check its NAT table:

If no translation entry exists, the router determines that the address 
10.1.1.1 must be translated, and sets up a translation of the inside 
local address 10.1.1.1 to a legal global address.

If overloading is enabled, and another translation is active, the 
router reuses the global address from that translation and saves 
enough information to be able to translate the global address back. 
This type of entry is called an extended entry.

In the original config you had the keyword "extended" int he static PATs, why did you remove it?

Does the dynamic PAT work?

Does static PAT work work if you temporarily remove the dynamic PAT?

Did clear the NAT table after changing the NAT configuration?

Did you issue some debug NAT and sh ip nat translation?

Rgds, MiKa

[crazyman143]

Forgive my naivety but I have read that excerpt on PAT before and I am still a bit fuzzy on what exactly "extendable" does. 

But to answer your questions and provide some more specifics: I do not have the extendable keyword in the new config, because the router doesn't allow it. I cannot use "extendable" at the end of a command when using an interface name instead of an actual IP in the static nat commands.

Also, this is partially working. There is a webserver on port 80 that I can see from outside. however VPN connections on ports 443, 500, 4500 do not work. It worked fine prior to this change. It will work again if I switch back to the old way.

PAT is working for other clients on the network, they have no issues reaching outside. I have tried some debugging but not sure what I'm looking for. Here is a partial of my nat table:

Pro Inside global         Inside local          Outside local         Outside global
tcp 97.84.XXX.XXX:80      10.1.1.2:80           75.140.119.204:58005  75.140.119.204:58005
tcp 97.84.XXX.XXX:80      10.1.1.2:80           75.140.119.204:58006  75.140.119.204:58006
tcp 97.84.XXX.XXX:80      10.1.1.2:80           ---                   ---
tcp 97.84.XXX.XXX:443     10.1.1.2:443          ---                   ---
udp 97.84.XXX.XXX:500     10.1.1.2:500          ---                   ---

So you can see that it is partially working but no translations appear on 443, 500. I tried adding esp protocol to my stateful inspection thinking it being a vpn tunnel could be getting blocked but it didn't affect it.

Hope i am making sense, thanks for  the help.

[m.kafka]

Hi crazy,

Yes you are making sense!

This is a challenge...

What does "debug ip nat" (with access-ist!) or a "debug ip packet detailed" (with access-list!) tell you? Any hints in the debug output? The config seems OK, the NAT table seem OK from what I can see.

Do you have a chance to capture packets on 10.1.1.2?

[Jon Marshall]

Your previous configuration that worked had an inbound acl that allowed all IP.

Your new configuration has a more specific inbound acl only allowing certain ports.

You can see the NAT is working because you are creating translations for the web server.

Can you temporarily just allow everything in the acl again which at least would tell us if NAT was the issue or whether it is your acl ie. traffic coming from the outside will be checked against the acl applied to that interface before any NAT occurs.

Jon

[crazyman143]

I did try that before. I just tried it again by adding the top line. Unfortunately no change. And you can see from the ACL that it has been allowing on those ports.

Extended IP access list Firewall
    5 permit ip any any (4 matches)
    10 permit tcp any any eq www (15 matches)
    20 permit tcp any any eq 443 (10 matches)
    30 permit udp any any eq isakmp
    40 permit udp any any eq non500-isakmp
    50 permit udp any any eq bootps
    60 permit udp any any eq bootpc (7 matches)

Edit: I have found that if I use the permit any any in the ACL, and also add this, it works. So it has to be that NAT isn't forwarding something it should be:

ip nat inside source static tcp 10.1.1.2 interface FastEthernet0/0

I have looked at the netstat on the vpn server also, to see if it's using any ports I've missed but the output only showed a connection on TCP 5000 (And yes I tried adding a static translation for 5000 but no good)

Thanks again folks for your help. Going to bed tonight, will troubleshoot more in the morning.