Announcement

Collapse
No announcement yet.

routing devices not doing what they're supposed to be doing?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • routing devices not doing what they're supposed to be doing?

    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:
    Code:
    inside 192.168.2xx.xxx 255.255.xxx.xxx 192.168.1xx.xxx 1 RIP
    here's the AT-9924:
    Code:
    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.

  • #2
    Re: routing devices not doing what they're supposed to be doing?

    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.
    Last edited by auglan; 15th September 2012, 13:41.
    CCNA, CCNA-Security, CCNP
    CCIE Security (In Progress)

    Comment


    • #3
      Re: routing devices not doing what they're supposed to be doing?

      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:

      Code:
      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:
      Code:
      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:

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

      Comment


      • #4
        Re: routing devices not doing what they're supposed to be doing?

        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.
        CCNA, CCNA-Security, CCNP
        CCIE Security (In Progress)

        Comment


        • #5
          Re: routing devices not doing what they're supposed to be doing?

          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.

          Code:
                                               /----------- server vlan/192.168.1
          router-----pix501-----at-9924------<
                                               \----------- workstation vlan/192.168.2
          here's the pix config:
          Code:
          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:
          Code:
          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:
          Code:
          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)
          Last edited by xyyz; 17th September 2012, 12:16.

          Comment


          • #6
            Re: routing devices not doing what they're supposed to be doing?

            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.
            CCNA, CCNA-Security, CCNP
            CCIE Security (In Progress)

            Comment


            • #7
              Re: routing devices not doing what they're supposed to be doing?

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

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

              Comment


              • #8
                Re: routing devices not doing what they're supposed to be doing?

                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.
                Last edited by auglan; 17th September 2012, 20:31.
                CCNA, CCNA-Security, CCNP
                CCIE Security (In Progress)

                Comment


                • #9
                  Re: routing devices not doing what they're supposed to be doing?

                  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?

                  Comment


                  • #10
                    Re: routing devices not doing what they're supposed to be doing?

                    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
                    CCNA, CCNA-Security, CCNP
                    CCIE Security (In Progress)

                    Comment


                    • #11
                      Re: routing devices not doing what they're supposed to be doing?

                      i'll get right on that. i don't know if this is significant, but the arp table on the pix doesn't show anything about the workstation vlan/subnet. is this normal? i vaguely remember something about arp being layer 2, which means the table should only show nodes within the same subnet, but i'm not sure.

                      Comment


                      • #12
                        Re: routing devices not doing what they're supposed to be doing?

                        Correct Arp is a layer 2 protocol. When a packet traverses a layer 3 interfaces the layer 2 address is rewritten, so you should only see arp entries for hosts on your subnet.
                        CCNA, CCNA-Security, CCNP
                        CCIE Security (In Progress)

                        Comment


                        • #13
                          Re: routing devices not doing what they're supposed to be doing?

                          alright, so i have the pix dumping everything to a syslog service on my pc. there's a lot of output, what should i look for? i don't see anything about dropping packets. most of what i see have to do with connections being built and torn down.

                          Comment


                          • #14
                            Re: routing devices not doing what they're supposed to be doing?

                            Look for any flows coming from that workstation subnet going out to the internet. If you dont see any issues there then maybe look at the upstream router. Do you have reachability to the workstation subnet from the pix?
                            CCNA, CCNA-Security, CCNP
                            CCIE Security (In Progress)

                            Comment


                            • #15
                              Re: routing devices not doing what they're supposed to be doing?

                              alright, i dumped the output to tftpd64 and i didn't see anything out of the ordinary. nothing about dropping packets.

                              again, what should i be looking for?

                              Comment

                              Working...
                              X