Options

Trouble with NAT

krjaykrjay Member Posts: 290
Hello all,

I'm having a bit of trouble with configuring NAT on my cisco router. My local network is able to get out to the internet as the 192.168.0.0 network gets translated to 1.1.1.2. The problem is I have a web server in that same local network I want to access via a second inside global IP address (1.1.1.3). When I insert the static NAT command for the web server (192.168.0.100), it becomes unable to ping anything on the internet. I believe I should be able to ping 1.1.1.3 from a device on the internet


I've supplied the relevant commands here:
interface FastEthernet0/0
 ip address 192.168.0.1 255.255.255.0
 ip nat inside

interface FastEthernet0/1
 ip address 1.1.1.2 255.255.255.248
 ip nat outside


ip route 0.0.0.0 0.0.0.0 f0/1

ip nat inside source list 5 interface f0/1 overload
ip nat inside source static 192.168.0.100 1.1.1.3

ACL 5 contains:
permit 192.168.0.0 0.0.0.255


I've also tried the following instead of the static NAT line above but it didn't work either:
ip nat inside source static tcp 192.168.0.100 80 1.1.1.3 80

I will post the actual config later when I have access so there may be a typo or two in my paraphrasing, however I think I'm doing something fundamentally wrong using multiple internet IPs.
2014 Certification Goals: 70-410 [ ] CCNA:S [ ] Linux+ [ ]

Comments

  • Options
    iamme4evaiamme4eva Member Posts: 272
    If you are trying to advertise 1.1.1.3 into the internet, I imagine your ISP will stop that unless you actually own the IP.
    Current objective: CCNA Security
    My blog: mybraindump.co.uk
  • Options
    krjaykrjay Member Posts: 290
    Sorry 1.1.1.1 was an example. The actual block of 2 IPs I'm using to test NAT we do own
    2014 Certification Goals: 70-410 [ ] CCNA:S [ ] Linux+ [ ]
  • Options
    JoeBirdsJoeBirds Member Posts: 49 ■■□□□□□□□□
    You are telling NAT to use 2 different public IP addresses to translate. You are telling it to use 1.1.1.3 with your source static command and 1.1.1.2 when you specify the fa0/1 interface with your overload command. Since the whole purpose of overloading is to use one IP address, you might be confusing your router with the conflicting commands. Trying removing the source static line to see if this fixes the issue.

    I realize that you're trying to keep your server at just 1.1.1.3, but your also telling it to be translated to 1.1.1.2 as the IP 192.168.0.100 is included in your access list as well. Might I suggest putting your server in a different VLAN. After you configure VLAN routing, you can create another static mapping to allow your server (which is now on another subnet) to be translated to 1.1.1.3:

    ip nat inside source static 172.16.1.1 1.1.1.3

    Something like that would work.
  • Options
    krjaykrjay Member Posts: 290
    Thanks for the reply, I will try putting the server on a different subnet. Do you think if I left everything the same except added a deny line in ACL 5 that denies the 192.168.0.100 host would work as well?
    2014 Certification Goals: 70-410 [ ] CCNA:S [ ] Linux+ [ ]
  • Options
    JoeBirdsJoeBirds Member Posts: 49 ■■□□□□□□□□
    Double check and ensure that your ISP is not using 1.1.1.3 on the other end of the link as that could also be what is causing the issue.
  • Options
    eteneten Member Posts: 67 ■■□□□□□□□□
    You shouldn't need a deny statement as statics have higher order of operation. Static NATs should appear in the translation table when you issue a "show ip nat trans" without needing an active translation.

    JoeBirds made a good point. Make sure your ISP isn't using that IP as your default route points to an interface. Can you ping 1.1.1.3 when you remove the static or do a traceroute to see if its in use? Do you have any ACLs or inspect rules? Can you run debugs?

    Below is an article from Cisco that is similar to your setup:
    Configuring Static and Dynamic NAT Simultaneously - Cisco Systems
  • Options
    krjaykrjay Member Posts: 290
    I think using the interface as the default route might have been my problem. I'm not sure why I did that in the first place, after going over my CCNA notes and reading material it never mentions any reason for doing that with the default route. It seems to be working in the lab setting (it did previously as well though). I will test it with the ISP some time this week.
    2014 Certification Goals: 70-410 [ ] CCNA:S [ ] Linux+ [ ]
Sign In or Register to comment.