[xyyz]

i'm a bit rusty here, so i would appreciate any help.

i'm using a pix501/6.3 and an allied telesis AT-9924T/2.7.6 (layer 3)

i have two vlans in the setup, one for the servers (192.168.1xx) and the other for the workstations (192.168.2xx). i have RIPv2 running on the the pix501 and AT-9924. they both broadcast and receive routes.

here's the pix:

inside 192.168.2xx.xxx 255.255.xxx.xxx 192.168.1xx.xxx 1 RIP

here's the AT-9924:

0.0.0.0           0.0.0.0           192.168.1xx.227     vlanxxx           48353
                  remote   0        rip        -        2                   400

i can ping the 192.168.2... network from the pix without any issues.

the problem is between the win7 workstations and win2k8r2 servers. they cannot communicate across the networks/vlans unless i enter a static route into each system.

i've been out of this field for a while, so i'm quite rusty, but i thought routing protocols handled all the routing details, and that the servers and workstations could be ignorant of the other networks because the layer 3 devices stored the routing tables and would route the traffic to and from the appropriate networks.

does anyone have any idea why this isn't working? any suggestions of what i should do to fix things?

while i know i can just take the time and put in static routes in all the devices, that is not what i want to do. i want to understand why this isn't working and then fix it.

again, thanks in advance for any help.

[auglan]

Make sure auto-summarization is disabled for rip version 2. It is on by default. Also Rip version 2 uses multicasts to 224.0.0.9 over udp port 520. Rip version 1 uses broadcast by default.


router rip
no auto-summary

Not sure how to do this on the other device.


Also with pix 6.3 code nat-control is always on. This means there has to be a nat translation when going from a higher security interface to a lower. (Example: Inside to dmz etc..) This was changed with 7.0 and higher as you can turn nat-control off. With 8.4 and above nat-control is gone completely.

[xyyz]

thanks for the response. mind telling me what those commands will do to help me?

you're right, the pix was broadcasting, which i needed because the pix is the default gateway. however, it wasn't listening for anything so i had to run:

rip inside passive version 2

with this the pix managed to populate it's routing table.

what i did, and again, this is a way to get around things, instead of making the pix the default gateway for the win7 and win2k8r2 machines, i set the default gateway to the AT-9924. with this, i was able to ping across the two vlan subnets.

however, after doing this, i encountered another problem.

the pix is on the servers' vlan subnet. anything on the same vlan subnet as the pix as no problems reaching the internet. on the other hand, any machine on the workstations' vlan - different subnet (obviously) - cannot get onto the internet.

the workstations can ping the inside interface of the pix, connect to the machines on the server vlan subnet, but the cannot get out of the pix.

i'm making an assumption that the pix is blocking traffic.

do i need to make a special rule to allow traffic from a different subnet through the pix?

this is the nat statement i have right now:

global (outside) 1 10.10.1xx.xxx netmask 255.255.xxx.xxx
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

initially, i had the following:

global (outside) 1 10.10.1xx.xxx netmask 255.255.255.xxx
nat (inside) 1 192.168.1xx.xxx 255.255.255.xxx
nat (inside) 1 192.168.2xx.xxx 255.255.255.xxx

but, i read that the 0.0.0.0 0.0.0.0 could be used to tell the pix to nat everything.

the other interesting thing is that the pix actually has records of the workstation vlan subnet in the xlate table, so at least it's taking it in, but sending it out is another matter.

[auglan]

Im assuming since the pix 501 has no vlan support that these vlans are setup on your L3 switch which should then have a default route to the pix. Would help to show how everything is connected and post the config of the pix. I am assuming the pix is your "internet" edge device.

[xyyz]

yes, the two vlans are setup on the AT-9924, which, if i haven't mentioned before, is layer 3 switch. and yes, the switch learned that the pix is the default router through rip. i posted some of the routing table information from the AT-9924 in my first post.

                                     /----------- server vlan/192.168.1
router-----pix501-----at-9924------<
                                     \----------- workstation vlan/192.168.2

here's the pix config:

PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxxxx encrypted
passwd xxxxxx encrypted
hostname xxxxx
domain-name xxxxx
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 ils 389
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 allow_ping permit icmp any any echo-reply
access-list allow_ping permit icmp any any source-quench
access-list allow_ping permit icmp any any unreachable
access-list allow_ping permit icmp any any time-exceeded
access-list 101 permit ip 192.168.1 255.255.255.x 10.10.1 255.255.255.x
access-list 102 permit ip 192.168.2 255.255.255.x 10.10.1 255.255.255.x
pager lines 24
logging on
logging facility 16
logging host inside 192.168.1xx
mtu outside 1500
mtu inside 1500
ip address outside 10.10.1xx 255.255.255.x
ip address inside 192.168.1xx 255.255.255.x
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNPool x
pdm history enable
arp timeout 14400
global (outside) 1 10.10.1xx netmask 255.255.255.x
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group allow_ping in interface outside
rip inside passive version 2
rip inside default version 2
route outside 0.0.0.0 0.0.0.0 10.10.1xx 2
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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
ntp server 192.168.1xx source inside
snmp-server host inside 192.168.1xx
no snmp-server location
no snmp-server contact
snmp-server community test
snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set trmset1 esp-aes-256 esp-sha-hmac
crypto dynamic-map map2 10 set transform-set trmset1
crypto map map 1 ipsec-isakmp
! Incomplete
crypto map map1 10 ipsec-isakmp dynamic map2
crypto map map1 interface outside
isakmp enable outside
isakmp key ******** address 10.10.1xx netmask 255.255.255.x
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup VPNpool address-pool VPNpool
vpngroup VPNpool dns-server 192.168.1xx
vpngroup VPNpool default-domain x
vpngroup VPNpool split-tunnel 102
vpngroup VPNpool idle-time 1800
vpngroup VPNpool password ********
telnet timeout 5
ssh 192.168.1x 255.255.255.x inside
ssh 192.168.2x 255.255.255.x inside
ssh timeout 60
console timeout 0
terminal width 80

here is the pix routing table:

outside 0.0.0.0 0.0.0.0 10.10.1xx 2 OTHER static
outside 10.10.1 255.255.255.x 10.10.1xx 1 CONNECT static
inside 192.168.1 255.255.255.x 192.168.1xx 1 CONNECT static
inside 192.168.2 255.255.255.x 192.168.1xx 1 RIP

here's a snapshot of the xlate table:

PAT Global 10.10.1xx(16831) Local 192.168.1xx(62172)
PAT Global 10.10.1xx(0) Local 192.168.2xx ICMP id 1
PAT Global 10.10.1xx(16832) Local 192.168.1xx(60727)

[auglan]

Traffic between your subnets should be routed through the L3 switch and not through the pix at all. Check on your switch to make sure it has routes for both subnets. It should show both subnets as connected routes. You nat looks fine on the pix. Is the upstream router doing nat again to your public ip space? Also I would create a separate subnet for your pix to switch connection. (Call it Internet Vlan etc..) Then advertise your workstation and server vlan along with the new subnet into rip. Also make sure you upstream router has a route back to both of your internal subnets.

[xyyz]

the AT-9924 is aware of all routes. here is the full routing table:

IP Routes
-------------------------------------------------------------------------------
Destination       Mask              NextHop             Interface           Age
                  Type     Policy   Protocol   Tag      Metrics      Preference
-------------------------------------------------------------------------------
0.0.0.0           0.0.0.0           192.168.1xx.xxx     vlan1xx          158155
                  remote   0        rip        -        2                   400
192.168.100.xxx   255.255.255.xxx   0.0.0.0             vlan1xx          158162
                  direct   0        interface  -        1                     0
192.168.200.xxx   255.255.255.xxx   0.0.0.0             vlan2xx          158162
                  direct   0        interface  -        1                     0
-------------------------------------------------------------------------------

initially, i didn't have any route command on the pix, but without it nothing on the 192.168.2xx vlan/subnet could ping the pix. i assume it's because the pix wasn't aware of the return path for the pings. this is why i've enabled the routing on the pix.

as for the external router, yeah, i have a double nat going on. everything comes out of a single PAT ip address, as you saw on the xlate table.

so setting a third vlan between the switch and the pix outta fix the problem? i'll try it, but the problem still remains that the 192.168.2xx vlan/subnet can get to the pix, but it's not leaving the pix for some reason. how did i test for that? i tried pinging the external router; the 192.168.1xx vlan/subnet can ping it without and problems, but the 192.168.2xxx vlan/subnet cannot.

i can see your point about making sure that the external router has a return path, but again, the source address, and therefore the return address, is the same PAT'ed address, which means that the external router is unaware of either vlan/subnet. yet, for some reason one vlan/subnet works, while the other doesn't.

[auglan]

Adding a separate subnet/vlan between the switch and pix helps keep your layer 2 broadcasts segmented. Since the pix inside interface is on the same subnet of the server vlan, then any broadcasts from that vlan will be heard on the pix's inside interface which is a waste of bandwidth/resources. I would create a new layer 3 interface on the switch and put the pix's inside interface in that subnet. You could make it a /30 as its only between 2 endpoints. To avoid the double nat I would also use nat exemption for your internal subnets.

Have you looked at any logs/debugs to see if traffic from the workstation subnet is being dropped?


Just to add I would get rid of the pix as its running really old code. May be worthwhile to replace it with an ASA.

[xyyz]

this is a home setup, not a production environment, so i'm not too worried about broadcasts, but nonetheless, i'll set it up the way you suggested after the problem's fixed. i'm worried that the setup will block traffic from the server vlan/subnet too, since, at the moment, the non-connected vlan/subnet can't pass traffic.

as for the debuging, what should i look for, and what should i enter for the debug statement? also, i assume that the statement will be applied onto the pix right?

[auglan]

I would start with the logs first. Since its not a production environment it should be safe to log to the console. If you find the output too much then you can send it to the buffer or syslog.


logging console 7

logging on