Cisco PIX 515E - Routing (ICMP & General) with Logical Interfaces

I am using the following configuration on my firewall;

PIX Version 6.3(3)
interface ethernet0 100full
interface ethernet1 100full
interface ethernet1 vlan21 physical
interface ethernet1 vlan201 logical
interface ethernet2 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
nameif vlan201 ilo security90
enable password ************ encrypted
passwd ************* encrypted
hostname ********
domain-name ********
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
access-list ilo_inside permit ip any host
access-list inside_ilo permit ip any host
access-list inside_ilo permit udp any host
access-list inside_ilo permit icmp any host
pager lines 24
icmp permit inside
icmp permit inside
icmp permit inside
icmp permit dmz
icmp permit dmz
icmp permit ilo
icmp permit ilo
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip address outside X.X.X.81
ip address inside
ip address dmz
ip address ilo
ip audit info action alarm
ip audit attack action alarm
pdm location ilo
pdm history enable
arp timeout 14400
global (outside) 1 X.X.X.82 netmask
global (dmz) 2 interface
global (ilo) 3 interface
nat (inside) 1 0 0
nat (dmz) 2 0 0
nat (ilo) 3 0 0
access-group inside_ilo in interface ilo
route outside X.X.X.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http inside
no snmp-server location
no snmp-server contact
snmp-server community ENG99
no snmp-server enable traps
floodguard enable
fragment chain 1 outside
fragment chain 1 inside
fragment chain 1 dmz
telnet inside
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80

In summary, there are three physical interfaces, with a second logical interface (ilo) defined on the inside interface.  
The inside interface is connected to a trunking port on my swtich = ilo = inside = dmz
X.X.X.0 = outsode (the X.X.X is the same in all replacements above)

The trunking appears to be working correctly as I can ping any machine on either VLAN from the firewall
I can ping any host on the DMZ from the firewall

My questions are;

1 - What have I missed out to allow me to ping from the to either the ilo or DMZ network?
2 - Similarly, what is missing to allow a ping from the ilo to DMZ or inside AND from the DMZ to ilo or inside?
3 - This may be the more basic issue, but what have I mssed out to get the routes to work correctly across the firewall?
Who is Participating?
I think you're getting it on the NAT/Global process.

Just remember that in this example:
global (outside) 1 XXX.XX.XXX.82 netmask
global (dmz) 1 interface
global (ilo) 1 interface
nat (inside) 1
nat (dmz) 1
nat (ilo) 1 255.255.0

Traffic passing from the nat address space "out" a global interface will use the same global number as the nat number
Traffic from DMZ out through the outside interface will use the outside global
traffic from ilo out through either the dmz interface to dmz servers, or out through the outside will use the appropriate global assigned to that interface that matches the nat number.
Also, if you use an address range as the outside global, then you will not be able to support more internal (actually, combines internal, dmz and ilo) hosts than you have number of available hosts in that subnet. You need to reserve at least one address as a PAT "overload", like:

global (outside) 1 XXX.XX.XXX.82 netmask
global (outside) 1  <-- no netmask, just one host ID

ACL questions:
1. No access-list need be applied at all to the inside interface
2. Correct
3. >I can't ping
Of course not. You cannot ping an interface from any other interface except it's own. You can't ping interface from anywhere except 10.7.20.x hosts. You cannot ping the outside interface from anywhere except outside. You cannot ping the inside interface from anywhere except an inside host. That's a "feature" behavior of the PIX that you cannot change.

You should be able to ping anything (host) in the dmz from the inside if you have something like this:
   access-list icmp_dmz permit icmp any echo-reply
   access-group icmp_dmz in interface dmz
Note the "any" because the icmp packet from the inside 10.7.4.x host gets translated to the dmz interface IP, so to the inside host it appears to be local.

One comment regarding acls. Remember that all traffic from higher security interface to lower security interface is automatically permitted, no access-list necessary i.e.
inside -> dmz, ilo, outside
dmz -> outside
ilo -> dmz, outside
Contrarily, all traffic from lower security interface to higher security interface is blocked by default:
outside -> in to any inteface
dmz - > in to ilo or inside
ilo - > in to inside
Unless, and until you put in an access list on the interface to permit the specified traffic. HOWEVER, once you do apply a single line acl, you must be sure to carefully consider and specify ALL the traffic that you want to pass, or you will block everything else. Example for your DMZ interface because traffic must pass both ways through this interface:

   access-list dmz_out permit tcp any eq http <-- go anywhere for web surfing
   access-list dmz_out permit tcp any eq https <- go places like Msoft update site
   access-list dmz_out permit tcp host eq http any  <-- allow your web server to serve up pages
   access-list dmz_out permit tcp host eq smtp any <-- allow your mail server to send mail
   access-list dmz_out permit udp any eq domain <-- allow dns outbound
   access-list dmz_out permit icmp any eq echo-reply

There is an implicit "deny all" at the end, so once you permit a single thing, like icmp only, then everything else is blocked by the unwritten, implicit deny all..

While on your outside interface, it is much simpler because all you have to do is permit only what you want to come in unsolicited:
   access-list outside_in permit tcp any host x.x.x.80 eq smtp
   access-list outside_in permit tcp any host x.x.x.80 eq www

Also, remember to ALWAYS re-apply the acl to the interface anytime you make changes to it, and remember, that it can only be applied "in" on any interface

1. to permit ping to either the ilo or the dmz, you need to explicitly permit icmp echo-reply in the interface acl:
>access-list ilo_inside permit ip any host
>access-group inside_ilo in interface ilo
By your acl, you should be able to ping from the one host only, which happens to be the PIX interface.. Suggest:

access-list ilo_inside permit icmp any echo-reply
access-group ilo_inside in interface ilo

Same for the DMZ interface:
access-list dmz_inside permit icmp any echo-reply
access-group dmz_inside in interface dmz

Also, you need to add more nat statements:
> nat (inside) 1 0 0
nat (inside) 2 0 0 <== needed to match global (dmz) 2 interface
nat (inside) 3 0 0 <== needed to match global (ilo) 3 interface

Similarly, you will need nat's for each interface to match the global or dmz:

> nat (ilo) 3 0 0
only get's you nat between ilo and global (ilo) 3, which is it's own interface. Not good.
Need to add:
no nat (ilo) 3 0 0
nat (ilo) 1 0 0  <== to match: global (outside) 1 X.X.X.82 netmask
nat (ilo) 2 0 0  <== to match: global (dmz) 2 interface

2. To ping from a higher security interface to a lower security interface requires an explicit access-list entry to the lower security interface.
To ping from DMZ to inside:

access-list dmz_inside permit icmp echo  <-- to ping inside or ilo
access-list dmz_inside permit icmp echo-reply  <- to respond to ping from ilo or inside
access-list dmz_inside in interface dmz

(yes, I know I goofed up in the first post for the dmz_inside acl)

3. Just remember that the PIX is not a router and will never be a router, nor behave exactly like a router. The concepts of security levels on each interface presents the biggest challenge.
Traffic from high - lower (i.e. inside to dmz, outside, ilo) is permitted by default
Traffic from lower to higher (i.e. dmz, ilo, or outside to inside) is blocked unles/until permitted by acl
On-Demand: Securing Your Wi-Fi for Summer Travel

Traveling this summer?Check out our on-demand webinar to learn about the importance of Wi-Fi security and 3 easy measures you can start taking immediately to protect your private data while using public Wi-Fi. Follow us today to learn more!

MarkNethercottAuthor Commented:
Thanks for your time on this.  The fog is starting to clear.
It all makes sense now you've explained it, especially the nat <=> global behaviour that I've been struggling with all afternoon.
I'm sure these mods will fix the issues - I'll try them out when I get back in to the office on Monday & let you know.
MarkNethercottAuthor Commented:
I've tried to get the NAT components to work correctly first and I've missed something in the logic....

I thought;

1 - Define a global list on the 'external' (or lower security level) interface that represents, so for my example,
outside  - global (outside) 1 XXX.XX.XXX.82 netmask
dmz - global (dmz) 2 interface <-- This will use for the PAT
ilo - global (dmz) 3 interface <-- This will use for the PAT

2 - Set up a NAT link between the 'internal' interface and the 'external' address pool using the global id number to pair the conbinations
This is where I get lost.  I figured this meant;
inside --> outside :- nat (inside) 1 (To restrict inside to outside NAT to hosts from the network)  <== Works
inside --> dmz :- nat (inside) 2 (To restrict inside to dmz NAT to hosts from the network) <== Fails "Error, duplicate NAT entry"
inside --> ilo :- nat (inside) 3 (To restrict inside to ilo NAT to hosts from the network) <== Fails "Error, duplicate NAT entry"

ilo --> outside :- nat (ilo) 1 (To restrict ilo to outside NAT to hosts from the network) <== Works
ilo --> dmz :- nat (ilo) 2 (To restrict ilo to dmz NAT to hosts from the network) <== Fails "Error, duplicate NAT entry"

dmz --> outside :- nat (dmz) 1 (To restrict dmz to outside NAT to hosts from the network) <== Works

A) What have I misunderstood?  How do you configure the interface <-> global mapping?  I can't see how the firewall knows how to NAT a packet from the inside interface to the DMZ correctly.
>Fails "Error, duplicate NAT entry"
Sorry if I lead you down the wrong path ....

Easy enough to fix.
Create one nat (inside) #

Not allowed:
nat (inside) 1
nat (inside) 2 <-- overlaps with #1

Create your globals with the same nat #
global (outside) 1 x.x.x
global (ilo) 1 interface
global (dmz) 1 interface

Source nat (inside) subnet is used

If you want different internal groups to use different global addresses, you can do something like:

global (outside) 1 x.x.x.x
global (outside) 2 x.x.x.y
global (outside) 3 x.x.x.z

nat (inside) 1
nat (inside) 2
nat (dmz) 3

Now, xlates sourced from inside on one subnet will go out as one global address, while the other subnet uses a different global address, while outbound from the dmz uses yet a 3d address. You can do lots of different things with this information. You can setup route-maps in the outside router, you can setup access-lists on the screening router, etc...

MarkNethercottAuthor Commented:
Ok, makes a bit more sense.

As a double check, does this mean that if I use the same ID for the global list.  Eg;
global (outside) 1 XXX.XX.XXX.82 netmask
global (dmz) 1 interface
global (ilo) 1 interface

And then use the NAT to point at the 1 group as well Eg;

nat (inside) 1
nat (dmz) 1
nat (ilo) 1 255.255.0

The the firewall figures out which NAT address to use on which interface.
MarkNethercottAuthor Commented:
Struggling a bit with the access-list creation at the moment;

A couple of supplementary quesitons

If I translate in to general English

access-list inside_dmz permit icmp any 255.255.255 echo
access-list inside_dmz permit icmp any 255.255.255 echo-reply
access-group inside_dmz in interface dmz

This means allow an echo & echo-reply in to the dmz interface if it comes from any host on the network and is directed to any host on the dmz interface

And I'll have to add this structure of access-list and group to each interface I want the ping to pass across, allowing for where the ping might have come from

A couple of quesitons
1 - Just taking inside to dmz, do I need to add a access-list statment to the inisde interface to allow the echo-reply from the dmz network back in.  eg.
access-list inside_icmp permit icmp any any echo-reply
access-group inside_icmp in interface inside
2 - If add this access-list in, then it breaks my current internet connectivity
3 - Even without (1) & (2), I can't ping even though I've got icmp permit dmz set in my config.
MarkNethercottAuthor Commented:
Fantastic - thanks.

1 - I think I've now understood NAT
2 - Ping now works - brilliant, thanks
3 - Access lists, I've almost got, but I'm missing a piece of the jigsaw to allow me to make a change and get an expected result.
What I've understood so far...
a - in a default configuration, all traffic from a higher to lower security interface is permitted and I believe this implies that all returning traffic from the lower security interface is permitted back through the original interface.
b - the 'in' direction for an interface is in to it from the local network. So for 'dmz' then 'in' is anything from (I must say that this 'in' direction is really hard to get clear from the documentation)
c - icmp is blocked by default 'in' to any interface.  This means (I think) - in the default condition - that icmp traffic can arrive from a higher security interface and and will pass through the interface to the 'local' device, which will respond, BUT the 'reply' isn't allowed 'in' to the interface so it gets dropped and the orginating host times out waiting for a response.
d - to allow icmp to work, an access-list needs to be added to the interface to allow the 'reply' in (which is what we've been doing - and now works)
e - however (!) once you've added an access-list to an interface, life gets more complicated, because all access-lists have an implicit deny at the end, which effectively stops (a). This means (conceptually, to me) that the behaviour of the interface is 'reversed' (wrt to the higher security interfaces) once the access-list is added.
f - to allow the interface to work 'correctly' again (albeit in a more controlled manner) a number of entries need to be added to allow the desired traffic from the local network 'in' to the LAN - including (I think) the return traffic from a higher security interface.

However what I don't understand is the following behaviour

On both the dmz (Security level 50) & the ilo (Security levlel 90) interfaces, I've set up similar access-lists eg;
  access-list xxx_dmz permit icmp 10.7.x.0 any echo-reply
  access-group xxx_dmz in interface xxx

i - Ping works fine
ii - I can access the http servers on the ilo network (unexpected based on 3e above) - why does this work, when it should be broken?
iii - I cannot establish an RDP session with a machine on the dmz network (expected based on 3e above).  
   - RDP works on port 3389.
   - However, if I add a line to allow traffic from the local network to travel 'in' to the interface on port 3389 (access-list icmp_dmz permit tcp any eq 3389) it still doesn't work
   - Is the PAT getting in the way?  If traffic is coming from to the dmz, it gets mapped to a port number on, eg 13684, so how do I direct the returning traffic (going 'in' to the dmz interface) correctly?
For ii, I think this is because you have "fixup protocol http" enabled, there is no equivalent for RDP 3389

iii For traffic from DMZ to ILO (lower-50 to higher-90), you need two things 1) access-list, 2) NAT
If you want traffic from lower to higher, then you must either setup a static NAT xlate for the port that you want, or system that you want to access, OR don't nat between these interfaces.


static (ilo,dmz) netmask
access-list dmz_in permit ip
access-list dmz_in permit icmp

Because of the fixups for http, https, ftp, and dns, you may still be able to get out from DMZ to Internet and browse
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.