Solved

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

Posted on 2004-09-10
10
893 Views
Last Modified: 2013-11-16
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
names
access-list ilo_inside permit ip any host 10.7.4.1
access-list inside_ilo permit ip any host 10.7.1.1
access-list inside_ilo permit udp any host 10.7.1.1
access-list inside_ilo permit icmp any host 10.7.1.1
pager lines 24
icmp permit 10.7.4.0 255.255.255.0 inside
icmp permit 10.7.1.0 255.255.255.0 inside
icmp permit 10.7.20.0 255.255.255.0 inside
icmp permit 10.7.4.0 255.255.255.0 dmz
icmp permit 10.7.1.0 255.255.255.0 dmz
icmp permit 10.7.4.0 255.255.255.0 ilo
icmp permit 10.7.20.0 255.255.255.0 ilo
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip address outside X.X.X.81 255.255.255.240
ip address inside 10.7.4.1 255.255.255.0
ip address dmz 10.7.20.1 255.255.255.0
ip address ilo 10.7.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location 10.7.1.1 255.255.255.255 ilo
pdm history enable
arp timeout 14400
global (outside) 1 X.X.X.82 netmask 255.255.255.128
global (dmz) 2 interface
global (ilo) 3 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
nat (dmz) 2 0.0.0.0 0.0.0.0 0 0
nat (ilo) 3 0.0.0.0 0.0.0.0 0 0
access-group inside_ilo in interface ilo
route outside 0.0.0.0 0.0.0.0 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 10.7.4.0 255.255.255.0 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 10.7.4.0 255.255.255.0 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

10.7.1.0 = ilo
10.7.4.0 = inside
10.7.20.0 = 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 10.7.4.0 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?
0
Comment
Question by:MarkNethercott
  • 5
  • 5
10 Comments
 
LVL 79

Expert Comment

by:lrmoore
Comment Utility
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 10.7.4.1
>access-group inside_ilo in interface ilo
By your acl, you should be able to ping from the one host 10.7.4.1 only, which happens to be the PIX interface.. Suggest:

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

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

Also, you need to add more nat statements:
> nat (inside) 1 0.0.0.0 0.0.0.0 0 0
add:
nat (inside) 2 0.0.0.0 0.0.0.0 0 0 <== needed to match global (dmz) 2 interface
nat (inside) 3 0.0.0.0 0.0.0.0 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.0.0 0.0.0.0 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.0.0 0.0.0.0 0 0  <== to match: global (outside) 1 X.X.X.82 netmask 255.255.255.128
nat (ilo) 2 0.0.0.0 0.0.0.0 0 0  <== to match: global (dmz) 2 interface

 
0
 
LVL 79

Expert Comment

by:lrmoore
Comment Utility
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 10.7.4.0 255.255.255.0 echo  <-- to ping inside or ilo
access-list dmz_inside permit icmp 10.7.4.0 255.255.255.0 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
0
 

Author Comment

by:MarkNethercott
Comment Utility
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.
0
 

Author Comment

by:MarkNethercott
Comment Utility
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 255.255.255.128
dmz - global (dmz) 2 interface <-- This will use 10.7.20.1 for the PAT
ilo - global (dmz) 3 interface <-- This will use 10.7.1.1 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 10.7.4.0 255.255.255.0 (To restrict inside to outside NAT to hosts from the 10.7.4.0 network)  <== Works
inside --> dmz :- nat (inside) 2 10.7.4.0 255.255.255.0 (To restrict inside to dmz NAT to hosts from the 10.7.4.0 network) <== Fails "Error, duplicate NAT entry"
inside --> ilo :- nat (inside) 3 10.7.4.0 255.255.255.0 (To restrict inside to ilo NAT to hosts from the 10.7.4.0 network) <== Fails "Error, duplicate NAT entry"

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

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

Questions
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.
0
 
LVL 79

Expert Comment

by:lrmoore
Comment Utility
>Fails "Error, duplicate NAT entry"
Sorry if I lead you down the wrong path ....


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

Not allowed:
nat (inside) 1 10.7.1.0
nat (inside) 2 10.7.1.0 <-- 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 10.7.1.0 255.255.255.0
nat (inside) 2 10.7.2.0 255.255.255.0
nat (dmz) 3 192.168.122.0 255.255.255.0

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...

0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 

Author Comment

by:MarkNethercott
Comment Utility
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 255.255.255.128
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 10.7.4.0 255.255.255.0
nat (dmz) 1 10.7.20.0 255.255.255.0
nat (ilo) 1 10.7.1.0 255.255.0

The the firewall figures out which NAT address to use on which interface.
0
 

Author Comment

by:MarkNethercott
Comment Utility
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 10.7.4.0 255.255.255 echo
access-list inside_dmz permit icmp any 10.7.4.0 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 10.7.4.0 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 10.7.20.1 even though I've got icmp permit 10.7.4.0 255.255.255.0 dmz set in my config.
0
 
LVL 79

Accepted Solution

by:
lrmoore earned 500 total points
Comment Utility
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 255.255.255.128
global (dmz) 1 interface
global (ilo) 1 interface
nat (inside) 1 10.7.4.0 255.255.255.0
nat (dmz) 1 10.7.20.0 255.255.255.0
nat (ilo) 1 10.7.1.0 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 255.255.255.128
global (outside) 1 xxx.xx.xxx.81  <-- 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 10.7.20.1
Of course not. You cannot ping an interface from any other interface except it's own. You can't ping 10.7.20.1 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 10.7.20.0 255.255.255.0 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 10.7.20.0 255.255.255.0 any eq http <-- go anywhere for web surfing
   access-list dmz_out permit tcp 10.7.20.0 255.255.255.0 any eq https <- go places like Msoft update site
   access-list dmz_out permit tcp host 10.7.20.22 eq http any  <-- allow your web server to serve up pages
   access-list dmz_out permit tcp host 10.7.20.23 eq smtp any <-- allow your mail server to send mail
   access-list dmz_out permit udp 10.7.20.0 255.255.255.0 any eq domain <-- allow dns outbound
   access-list dmz_out permit icmp 10.7.20.0 255.255.255.0 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
 <etc>

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

   
0
 

Author Comment

by:MarkNethercott
Comment Utility
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 10.7.20.0 (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 255.255.255.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 10.7.20.0 255.255.255.0 any eq 3389) it still doesn't work
   - Is the PAT getting in the way?  If traffic is coming from 10.7.4.221:3389 to the dmz, it gets mapped to a port number on 10.7.1.1, eg 13684, so how do I direct the returning traffic (going 'in' to the dmz interface) correctly?
0
 
LVL 79

Expert Comment

by:lrmoore
Comment Utility
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.

Example:

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

Because of the fixups for http, https, ftp, and dns, you may still be able to get out from DMZ to Internet and browse
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

To setup a SonicWALL for policy based routing to be used with the Websense Content Gateway there are several steps that need to be completed. Below is a rough guide for accomplishing this. One thing of note is this guide is intended to assist in the…
This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
You have products, that come in variants and want to set different prices for them? Watch this micro tutorial that describes how to configure prices for Magento super attributes. Assigning simple products to configurable: We assigned simple products…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now