cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1610
Views
0
Helpful
15
Replies

pix routing-classless or classful??

lxnancy
Level 1
Level 1

We have a subnetted class C as our inside network on a pix running 6.1. We are attempting to communicate with another subnet of that same class c on the outside, with no success. Does the pix recognize classless routing? If not by default, how do we turn it on? We are running 6.1 code.

15 Replies 15

steve.barlow
Level 7
Level 7

Do you have a static route to those networks? If you are using RIP, make sure it's RIP 2.

Steve

we have a default route pointing to the outside interface.. and we even hardcoded the outside subnet to point out that inteface.. but it still doesn't work. i can ping from any other interface on that outside router-except the subnet of the "shared" class c..

Can you post the relevant configs (IPs and routes)? Can you debug icmp to see if the PIX sends it out the correct interface (debug icmp trace and/or debug packet ...)?

Steve

heres the router config:

interface FastEthernet0/0

no ip address

no ip directed-broadcast

speed 100

full-duplex

!

interface FastEthernet0/0.300

description Ethernet to NAMM Private LAN s1-namrmf

encapsulation dot1Q 300

ip address 208.242.100.65 255.255.255.224

no ip redirects

no ip directed-broadcast

!

interface FastEthernet0/1

no ip address

no ip directed-broadcast

speed 100

full-duplex

!

interface FastEthernet0/1.162

description Ethernet to PSC DMZ s1-namptc for NAMM/PSC access

encapsulation dot1Q 162

ip address 165.136.127.165 255.255.255.248

no ip redirects

no ip directed-broadcast

ip nat outside

ip route 208.242.100.128 255.255.255.128 FastEthernet0/1.162

and the pix:

nameif ethernet0 outside security0

nameif ethernet1 inside security100

access-list acl-out7 permit icmp any any

access-list acl-out7 permit tcp host 208.242.100.78 host 208.242.100.144 eq ftp

access-list acl-out7 permit tcp host 208.242.100.94 host 208.242.100.144 eq ftp

ip address outside 165.136.34.1 255.255.255.240

ip address inside 208.242.100.129 255.255.255.128

route outside 0.0.0.0 0.0.0.0 165.136.34.13 1

(we also tested adding a specific route to 208.242.100.64 255.255.255.224 1665.136.34.13)

pings from the router... first is sourced from the network in question.. the second is just a straight ping (sourcing fromthe outbound interface)...

r1-namptc#ping

Protocol [ip]:

Target IP address: 208.242.100.144

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 208.242.100.65

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 208.242.100.144, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

r1-namptc#ping 208.242.100.144

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 208.242.100.144, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

I will try to get the debug info...

THANKS!

-What does your ip nat access-list look like on your router, where is the inside? Is traffic permitted to the 208.242.100.129 255.255.255.128 network?

-If you add the keyword "log" to the access-list acl-out7 permit icmp any any, does it show any hits (if yes what is the source IP)? If you do a show log it should show if the PIX is denying them (which I doubt).

-What does your static mapping on the PIX look like - static (inside,outside) 208.242.100.x 208.242.100.x netmask x.x.x.x or is it nat (inside) 0?

-What did the debugs show?

Let me know.

Steve

ok.. on the router.. the inside interfaces are serial links-we are natting unregistered addresses from our remote sites to registered before they enter our dmz to access other hosts on that network.. there is no natting currently setup for any 208.242.100.x addresses-however, if I nat that address it works.. but I need it to work native because too many other users in the dmz already access the servers on the native addresses. Here are the commands in the pix for nat:

nat (inside) 0 208.242.100.128 255.255.255.128 0 0

static (inside,outside) 208.242.100.132 208.242.100.132 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.140 208.242.100.140 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.141 208.242.100.141 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.151 208.242.100.151 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.150 208.242.100.150 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.152 208.242.100.152 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.153 208.242.100.153 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.154 208.242.100.154 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.155 208.242.100.155 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.156 208.242.100.156 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.170 208.242.100.170 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.144 208.242.100.144 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.157 208.242.100.157 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.158 208.242.100.158 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.171 208.242.100.171 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.180 208.242.100.180 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.159 208.242.100.159 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.185 208.242.100.185 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.186 208.242.100.186 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.187 208.242.100.187 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.160 208.242.100.160 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.161 208.242.100.161 netmask 255.255.255.255 0 0

static (inside,outside) 208.242.100.162 208.242.100.162 netmask 255.255.255.255 0 0

I should have the debug info and log info this afternoon.. unfortunately I don' t have access to the pix, so I have to have the fw guys do it... In a nutshell, other networks off my router can get to the 208.242.100.128 network, but my 208.242.100.64 network can't.

208.242.100.128 net ---- PIX --- DMZ RTR--- NAMM RTR---- 208.242.100.64 net

Last gasp/straw before seeing debugs, does DMZ RTR have a route to 208.242.100.64/29 and have ip classless? Can the PIX ping 208.242.100.65 (if yes to these first 3 questions it looks like a translation issue)?

I may try static (inside,outside) 208.242.100.128 208.242.100.128 netmask 255.255.255.128 instead of all the individual statics. Shouldn't make a diff but you never know.

Steve

ok.. yes the dmz rtr has routes to 208.242.100.65/27 255.255.255.224 and ip classless.. and a route to 208.242.100.128/25 as well... below is the info from the debugs:

f1-diadptc#debug icmp trace (this is from an address that has a src which has the same class C network as my inside network yet it is actually

on a different mask than my inside so therefore it should be a different network)

801: Inbound ICMP echo request (len 72 id 61448 seq 3497) 208.242.100.65 > 208.242.100.144 > 208.242.100.144

810: Inbound ICMP echo request (len 72 id 61704 seq 3497) 208.242.100.65 > 208.242.100.144 > 208.242.100.144

819: Inbound ICMP echo request (len 72 id 61960 seq 3497) 208.242.100.65 > 208.242.100.144 > 208.242.100.144

844: Inbound ICMP echo request (len 72 id 62216 seq 3497) 208.242.100.65 > 208.242.100.144 > 208.242.100.144

853: Inbound ICMP echo request (len 72 id 62472 seq 3497) 208.242.100.65 > 208.242.100.144 > 208.242.100.144

f1-diadptc#debug icmp trace (this is from an address that has a src address from a different network than what is on my pix)

946: Inbound ICMP echo request (len 72 id 39436 seq 7972) 165.136.127.165 > 208.242.100.144 > 208.242.100.144

947: Outbound ICMP echo reply (len 72 id 39436 seq 7972) 208.242.100.144 > 208.242.100.144 > 165.136.127.165

948: Inbound ICMP echo request (len 72 id 39692 seq 7972) 165.136.127.165 > 208.242.100.144 > 208.242.100.144

949: Outbound ICMP echo reply (len 72 id 39692 seq 7972) 208.242.100.144 > 208.242.100.144 > 165.136.127.165

950: Inbound ICMP echo request (len 72 id 39948 seq 7972) 165.136.127.165 > 208.242.100.144 > 208.242.100.144

951: Outbound ICMP echo reply (len 72 id 39948 seq 7972) 208.242.100.144 > 208.242.100.144 > 165.136.127.165

952: Inbound ICMP echo request (len 72 id 40204 seq 7972) 165.136.127.165 > 208.242.100.144 > 208.242.100.144

953: Outbound ICMP echo reply (len 72 id 40204 seq 7972) 208.242.100.144 > 208.242.100.144 > 165.136.127.165

954: Inbound ICMP echo request (len 72 id 40460 seq 7972) 165.136.127.165 > 208.242.100.144 > 208.242.100.144

955: Outbound ICMP echo reply (len 72 id 40460 seq 7972) 208.242.100.144 > 208.242.100.144 > 165.136.127.165

f1-diadptc# debug packet outside src 208.242.100.65 dst 208.242.100.144 proto icmp

f1-diadptc# --------- PACKET ---------

-- IP --

208.242.100.65 ==> 208.242.100.144

ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x64

id = 0x1db flags = 0x0 frag off=0x0

ttl = 0xfe proto=0x1 chksum = 0x5007

-- ICMP --

type = 0x8 code = 0x0 checksum=0xd297

identifier = 0x1e68 seq = 0x89d

-- DATA --

0000001c: 00 00 00 03 4a 96 3a 14 ab cd ab cd ab cd ab cd | ....J.:.........

0000002c: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

0000003c: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

0000004c: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

0000005c: ab cd ab cd ab cd ab cd c4 | .........

--------- END OF PACKET ---------

--------- PACKET ---------

-- IP --

208.242.100.65 ==> 208.242.100.144

ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x64

id = 0x1dc flags = 0x0 frag off=0x0

ttl = 0xfe proto=0x1 chksum = 0x5006

-- ICMP --

type = 0x8 code = 0x0 checksum=0xcac6

identifier = 0x1e69 seq = 0x89d

-- DATA --

00000014: 00 00 00 03 4a 96 41 e4 | ....J.A.

00000024: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000034: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000044: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000054: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000064: 32 | 2

--------- END OF PACKET ---------

--------- PACKET ---------

-- IP --

208.242.100.65 ==> 208.242.100.144

ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x64

id = 0x1dd flags = 0x0 frag off=0x0

ttl = 0xfe proto=0x1 chksum = 0x5005

-- ICMP --

type = 0x8 code = 0x0 checksum=0xc2f5

identifier = 0x1e6a seq = 0x89d

-- DATA --

0000001c: 00 00 00 03 4a 96 49 b4 ab cd ab cd ab cd ab cd | ....J.I.........

0000002c: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

0000003c: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

0000004c: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

0000005c: ab cd ab cd ab cd ab cd 5b | ........[

--------- END OF PACKET ---------

--------- PACKET ---------

-- IP --

208.242.100.65 ==> 208.242.100.144

ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x64

id = 0x1de flags = 0x0 frag off=0x0

ttl = 0xfe proto=0x1 chksum = 0x5004

-- ICMP --

type = 0x8 code = 0x0 checksum=0xbb24

identifier = 0x1e6b seq = 0x89d

-- DATA --

00000014: 00 00 00 03 4a 96 51 84 | ....J.Q.

00000024: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000034: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000044: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000054: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000064: 31 | 1

--------- END OF PACKET ---------

--------- PACKET ---------

-- IP --

208.242.100.65 ==> 208.242.100.144

ver = 0x4 hlen = 0x5 tos = 0x0 tlen = 0x64

id = 0x1df flags = 0x0 frag off=0x0

ttl = 0xfe proto=0x1 chksum = 0x5003

-- ICMP --

type = 0x8 code = 0x0 checksum=0xb353

identifier = 0x1e6c seq = 0x89d

-- DATA --

00000014: 00 00 00 03 4a 96 59 54 | ....J.YT

00000024: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000034: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000044: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000054: ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd | ................

00000064: 20 |

--------- END OF PACKET ---------

This proves the pix receives the packets and NATs them (as shown by 208.242.100.144 > 208.242.100.144). The next step in the troubleshooting saga would be to place a sniffer on the 208.242.100.128 subnet (just after the PIX) to see if the PIX actually forwards it out it's interface. I suspect not, but the sniffer will prove it. Can this be done?

I suspect a NAT issue, not routing (can the pix ping 208.242.100.65 - if yes it's not routing).

Steve

no, the pix cannot ping 208.242.100.65 either. We are verifying all the server subnet masks right now(tho I know the router mask is correct) and will test again.. If it still fails, ideas?

PIX can't ping even with a static route, interesting. Can you turn on RIP2 on the PIX, the DMZ RTR and the NAMM RTR (passive interface all interfaces except those needed)? By using RIP2, we know it should understand VLSM. Right now your network is staring at a discontiguous network. RIP 2 shouldn't care about this though.

If that fails, I have failed and can only suggest:

1)TAC

2)using NAT on a router

3)creating a GRE tunnel between both 208.242.100.x networks and use acls as security.

Let me know.

Thanks

Steve

Try do a 'sh route' on the pix, and post it up...

the pix has 2 directly connected interfaces and a default route.. no routing protocols, no static routes except the default.

Steve... thanks for all of your help.. RIP2 won't be an answer, cause they don't want it on in the dmz.. We are thinking TAC, and trying out NAT now(I'm waiting on the fw changes as we speak).. I hadn't considered a tunnel.. so that's an idea too. You haven't failed.. you've been a great help! I'll post what we do to get around it and what the ultimate answer is.. if we find one... Long term these 2 networks will merge together, so I'm investigating how quickly we can make that happen too.

Review Cisco Networking for a $25 gift card