No route to/from the same subnet???

[SteveGodfrey]

Suggestions?

.2 and .3 are W2K servers with the correct mask and gateway (.1 the PIX)

110001: No route to 192.168.161.2 from 192.168.161.3

PIX config

ip address DMZ-slot:3 192.168.161.1 255.255.255.0

Why would the PIX be picking up these packets when the devices should be communicating directly?

[l.mourits]

Hi,

There are several items that could give you this type of behaviour on the PIX firewall, however, all of them are just misconfigurations of your PIX.

Most likely one with this kind of message is that you have a static command in place which overlaps whit your address space on the dmz interface, or that you have nat and global commands in place which overlap each other.

If you can post your config (remember to remove passwords and outside IP adresses) I can have a look for you, if you like.

I had exactly the same problem once due to an overlap in static, nat and global commands.

Kind Regards,

Leo

[SteveGodfrey]

Here you go.....

We're not doing any NAT in any direction.

PIX Version 6.3(1)

interface ethernet1 100full

interface ethernet3 10baset

nameif ethernet1 inside security100

nameif ethernet3 DMZ-slot:3 security20

icmp permit any inside

icmp permit any DMZ-slot:3

ip address inside 10.22.4.5 255.255.252.0

ip address DMZ-slot:3 192.168.161.1 255.255.255.0

ip address DMZ-slot:4 192.168.151.1 255.255.255.0

ip verify reverse-path interface outside

arp timeout 14400

nat (inside) 0 0.0.0.0 0.0.0.0 0 0

nat (Failover) 0 0.0.0.0 0.0.0.0 0 0

nat (DMZ-slot:3) 0 0.0.0.0 0.0.0.0 0 0

nat (DMZ-slot:4) 0 0.0.0.0 0.0.0.0 0 0

static (inside,DMZ-slot:3) 10.0.0.0 10.0.0.0 netmask 255.0.0.0 0 0

static (inside,DMZ-slot:3) 193.35.0.0 193.35.0.0 netmask 255.255.0.0 0 0

static (inside,DMZ-slot:3) 192.0.0.0 192.0.0.0 netmask 255.0.0.0 0 0

static (inside,DMZ-slot:3) 202.0.0.0 202.0.0.0 netmask 255.0.0.0 0 0

static (inside,DMZ-slot:3) 198.0.0.0 198.0.0.0 netmask 255.0.0.0 0 0

access-group ACL-inside in interface inside

access-group ACL-DMZ-slot:3 in interface DMZ-slot:3

route inside 0.0.0.0 0.0.0.0 10.22.4.1 1

route inside 10.0.0.0 255.0.0.0 10.22.4.1 1

route inside 172.0.0.0 255.0.0.0 10.22.4.1 1

route inside 192.168.0.0 255.255.0.0 10.22.4.1 1

route DMZ-slot:3 192.168.37.0 255.255.255.0 192.168.161.4 1

route DMZ-slot:3 192.168.50.0 255.255.255.252 192.168.161.7 1

route DMZ-slot:3 192.168.50.4 255.255.255.252 192.168.161.7 1

route DMZ-slot:3 192.168.50.8 255.255.255.252 192.168.161.7 1

route DMZ-slot:3 192.168.50.12 255.255.255.252 192.168.161.7 1

route DMZ-slot:3 192.168.51.0 255.255.255.248 192.168.161.7 1

route DMZ-slot:3 192.168.51.8 255.255.255.248 192.168.161.7 1

route DMZ-slot:3 192.168.51.16 255.255.255.248 192.168.161.7 1

route DMZ-slot:3 192.168.51.24 255.255.255.248 192.168.161.7 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

[l.mourits]

Hi,

Okay, clear to me. I allready know what is causing your problem (indeed an overlap, as said earlier)

I will try to explain what is happening right now.

Since the PIX will do proxy-ARP based on the static commands, the static commands on your PIX are doing proxy-ARP for all following networks (whenever there is an ARP request on your DMZ interface):

- 10.0.0.0/8

- 193.35.0.0/16

- 192.0.0.0/8

- 202.0.0.0/8

- 198.0.0.0/8

If we look into this with more detail, and take a look at one specific command on you config, namely:

static (inside,DMZ-slot:3) 192.0.0.0 192.0.0.0 netmask 255.0.0.0 0 0

This means you're telling your PIX that all networks within 192.0.0.0/16 resides on the inside interface and that the PIX should proxy-ARP for all these addresses, so also on the address 192.168.161.2 and 192.168.161.3, while in your config it is easy to determine that this is not the case, since the subnet 192.168.161.0/24 resides on your DMZ interface.

It's obvious that you also have subnets within 192.168.x.x on your inside network, but in this case you would have to change the config a little bit to get it work.

Here's the changes on config what should solve your problem:

static (inside,DMZ-slot:3) 192.168.x.0 192.168.x.0 netmask 255.255.255.0

(repeat this line for every class C network which really resides on the inside network)

(you could also use other subnetmasks to get less lines on your config, but you have to prevent that the network 192.168.161.0/24 falls within this static statements). You have to get ride of this overlap, cause that is what is causin' your troubles.

When all required statics are in place, then remove the static command which is in place right now with the command:

no static (inside,DMZ-slot:3) 192.0.0.0 192.0.0.0 netmask 255.0.0.0 0 0

Then do a clear xlate, and you should be up and running again.

Hope this helps. If things are not clear yet, do not hesitate asking.

Good luck and Kind Regards,

Leo

[SteveGodfrey]

Well that certainly explains the problems I was seeing, for instance two of the hosts on the DMZ would randomly loose IP connectivity which seemed crazy because they were on the same subnet therefore wouldn't need to use the DG to 'see' each other.

I made the suggested changes on the PIX and did a clear x but was still having some problems but I'm pretty sure they are just more config issues, I also wanted to re-boot the two servers but I couldn't get into that part of the lab :(

So I need to remove any static that references the dmz subnet (192.168.161.0).

OK then here's another question then!

In order for the hosts on the DMZ to access the internet (which is via a different PIX) I will need to add a static for every external network then?

I have another look Monday.

Thanks for the very thorough explaination.

I did the PIX course a while back but as it was all new I could never see this type of scenario arising, if I could re-do the course I'd have a load more questions ;)

[l.mourits]

Hello again,

Glad I could help with the first item. You second question is a bit more difficult to explain, if I understand you correctly, then your Internet connection resides on the inside of your network (if we look at this from the dmz). Is this correct?

Anyway, normally for systems to enable them to initiate sessions you will need nat and global statements. Till version 6.2 this was only possible from a high level security interface to a low level security interface, from version 6.3 this is also possible from low level security interface to high level security interface, so, if you´re on 6.3 (or higher *duh :-S*) there´s no need for adding static´s for all networks, just put in a nat and global statement, and prevent you internel traffic from being translated with binding a nat 0 with appropiate access-list to the dmz interface.

If the other PIX which delivers the Interetfeed resides on the outside of the PIX we are talking about then you do not need 6.3, cause earlier version allready support this :-)

Hope this helps,

Kind Regards,

Leo

Kind regards,

Leo

[l.mourits]

Bytheway, I did not do any PIX course, did train myself via CCO, error and trial and testing a lot

When I did my first "PIX-gig", there was no course available here in Europe yet, so, I was kind of forced to get into it myself.

But don´t tell anyone, okay :-))))