Static and Dynamic Rules Not Working Together

Unanswered Question
Apr 19th, 2010
User Badges:

I'm certain I'm doing something wrong in my (simple) test config. I know I can do this as I have a PIX 515e doing this in another office. I'm trying to establish a single IP on the outside that inside hosts can use to access the internet - PAT. Then I'd like to selectively publish, for example, web servers and establish a handful of static NAT entries and manage those 1 to 1 IPs with ACLs. It seems simple but I'm botched something.


With the dynamic config in place, all hosts behing the internal interface can access the internet without any issues. As soon as I add the static NAT entry for the web server, it can no longer access the internet (nor does the static rule seem to work).


Web Server Outside:    1.1.1.11

Web Server Inside:       10.10.1.1

Outside Int IP:              1.1.1.1


global (outside) 101 interface
nat (inside) 101 10.10.0.0 255.255.224.0
static (inside,outside) 1.1.1.11 10.10.1.1 netmask 255.255.255.255


I've also attached the config in case that helps.


Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Federico Coto F... Mon, 04/19/2010 - 13:26
User Badges:
  • Green, 3000 points or more

Hi,


If as soon as adding the STATIC rule, Internet stops working and the STATIC rule does not work, most likely is because the public IP used in the STATIC is used somewhere else?


Make sure is not the same as the PIX's default gateway.

(In your configuration you have 5.5.5.5 as the next-hop, but obviously that is not the case).


Make sure that there's no overlapping with the public IP used in the STATIC on your PIX.


Federico.

mhcraig Mon, 04/19/2010 - 14:20
User Badges:

The 5.5.5.5 represents the gateway router in front of the PIX. I just changed the IPs for the post here.


Yes, once I add the static rule:

static (inside,outside) 1.1.1.11 10.10.1.1


Then I can no longer access the internet from sitting at the desktop of the web server (10.10.1.1).


However, all other hosts in the 10.10.0.0 subnet CAN still access the internet with the web servers static rule in place.


Hope that helps - thanks for the reply,


-h

Federico Coto F... Mon, 04/19/2010 - 14:26
User Badges:
  • Green, 3000 points or more

The public IP used in the STATIC is in the same subnet as the outside IP of the PIX correct?


Can you use a different public IP for the STATIC statement to see if it makes any difference?

For example, instead of 1.1.1.11 use 1.1.1.12 (this has to be an available IP in the same subnet range)


If the public IP is a valid IP (belonging to the same subnet as the outside IP of the PIX), and there's no filtering for that IP, it should work.


Try with a different public IP on the STATIC please.


Federico.

mhcraig Mon, 04/19/2010 - 14:46
User Badges:

Correct. We have a small /27 network for use that was allocated by a provider. I changed the IPs for the post but it is effectively:


1.1.1.0/27

1.1.1.1 - 1.1.1.30


I just tried

static (eth-saas,eth-twt) 1.1.1.20 10.10.1.1


I did notice that I messed up the subnet mask of the outside interface. I had 240 when it should have been 224. I fixed that problem but still no luck.


interface Ethernet0
  nameif eth-twt
  security-level 0
  ip address 1.1.1.1 255.255.255.224
!


Thanks again,


-h

Federico Coto F... Mon, 04/19/2010 - 15:06
User Badges:
  • Green, 3000 points or more

So, the server can get to the Internet when using regular Dynamic NAT/PAT, i.e


nat (inside) 1 0 0

global (outside) 1 interface


But the server can't get to the Internet when configuring the STATIC NAT, i.e


static (in,out) x.x.x.x 1.1.1.1


This only tells me that there's a problem with the public IP being used in the STATIC statement or there is an ACL applied denying traffic on that IP (neither of those applies to this case correct?)


Do the following then...

Create the STATIC NAT again, and the connection to the Internet from the serve fails correct?


Launch the Packet Tracer utility from ASDM (or from CLI) to emulate the connection to the Internet from that server and see what fails on the ASA.


Federico.

mhcraig Mon, 04/19/2010 - 17:26
User Badges:

I've done this - and just did again to be sure - and it goes through the animation with the final result of "the packet is allowed". It's so strange.


To me that suggests an ACL: problem back inbound but it's going from an interface with a security level of 100 to the outside which is 0. I thought we don't need an "established" ACL entry....


(Tomorrow I may try to use some private IPs on both sides and start over. I have the PIX facing the internet with a globally unique IP that I eventually plan to use. Until Iget this worked out I may need to resort to all test IPs and drop a switch on each side.)


Is there something in my original (attached to first post) config that I'm missing to allow the  return packets from a static vs. dynamic entry?

mhcraig Tue, 04/20/2010 - 06:19
User Badges:

Federico-


I think the problem is solved. You were right in confirming that the configuration looked fine and it should be working. In the end there was nothing wrong with the config. A routing statement on a router was causing the issue.


I thought I would post and update as I'm sure this happens to other people - it's a simple thing to overlook:


My issue all boiled down to routing statements on a router on the outside of the PIX. There was a route statement on the outside router to the effect of:

ip route 1.1.1.0 255.255.255.224 FastEthernet0/0 (Old Gateway Here)


When I was using a global IP and using the interface's own IP, the outside router knew - via ARP - where to send the packets back to. As soon as I tried to use a static rule then the router tried to send the packets to the current PIX that I'm planning to replace! The outside router wasn't sending the packets to the right PIX. I realized this after not seeing them logged coming back in.


All I did was remove the above old routing statement and replace it with:

ip route 1.1.1.0 255.255.255.224 FastEthernet0/0 1.1.1.1


And now static and dynamic ruls work just fine.


Thank you for troubleshooting this with me. It was helpful to confirm I was on the right track.


-h

Actions

This Discussion