Pix and VLANs - what the F?

Discussion in 'Cisco' started by Irakli Natsvlishvili, Jul 18, 2004.

  1. Ok, MAYBE I do not understand something and please help me. It will be
    long post. Hoping you can help

    We know, that pix is built on following foundation - if packet came
    from one interface then forward it to another interface or drop it.

    Now, since 6.3(3) VLANs were introduced and the whole VLAN concept
    makes nonsense above statement. In case of VLAN you can have multiple
    logical interfaces on one physical and allow communication between
    them. In this case the above statement is true if you add work
    'logical' in it.

    Here is my config. I have 515 UR Two interfaces only. Inside (security
    100) and Outside (0). Inside interface is connected to C2950c Catalyst
    on port F0/1.

    Here is the list what I did:

    1. I created two logical interfaces on Pix with VLAN 200 and 500 and
    assigned them to different security zones:

    interface ethernet1 vlan200 logical
    interface ethernet1 vlan500 logical

    nameif vlan200 dmz security50
    nameif vlan500 vonage security20

    2. I assigned Pix inside physical interface to VLAN 100:

    interface ethernet1 vlan100 physical

    3. On Switch, I made port F0/1, where Pix's inside interface is
    connected, a trunk port and removed VLAN1 from that port:

    interface FastEthernet0/1
    description Pix internal interface - trunk
    switchport trunk allowed vlan 2-4094
    switchport mode trunk
    no ip address
    no logging event link-status
    spanning-tree portfast

    4. On switch I defined three ports for each VLAN and made them access
    ports. F0/16 - VLAN 100 (internal), F0/22 - VLAN 200 (DMZ), F0/24 -
    VLAN 500 (Vonage):

    interface FastEthernet0/16
    description Internal netork - 10.1.1.0/24
    switchport access vlan 100
    switchport trunk allowed vlan 100
    switchport mode access
    no ip address
    no logging event link-status
    spanning-tree portfast

    interface FastEthernet0/22
    description DMZ network - 192.168.102.0/24
    switchport access vlan 200
    switchport trunk allowed vlan 200
    switchport mode access
    no ip address
    no logging event link-status
    spanning-tree portfast

    interface FastEthernet0/24
    description Vonage - 172.20.30.0/24
    switchport access vlan 500
    switchport trunk allowed vlan 500
    switchport mode access
    no ip address
    no logging event link-status
    spanning-tree portfast

    5. On switch Vlan1 is shutdown:

    interface Vlan1
    no ip address
    no ip route-cache
    shutdown
    !
    interface Vlan100
    ip address 10.1.1.10 255.255.255.0
    ip accounting output-packets
    ip accounting mac-address input
    ip accounting mac-address output
    ip accounting precedence input
    ip accounting precedence output
    ip accounting access-violations
    no ip route-cache

    6. On pix I assigned IP address to logical interfaces:

    System IP Addresses:
    ip address inside 10.1.1.1 255.255.255.0
    ip address dmz 192.168.102.100 255.255.255.0
    ip address vonage 172.20.30.1 255.255.255.0


    Result - with this config everything works in terms of accessing to
    the Internet. All workstations call access to the internet at the same
    time, the is no error in pix's or switch's log:

    homepix(config)# sh int e1

    interface ethernet1 "inside" is up, line protocol is up

    IP address 10.1.1.1, subnet mask 255.255.255.0
    MTU 1500 bytes, BW 100000 Kbit full duplex
    14902 packets input, 2610732 bytes, 0 no buffer
    Received 388 broadcasts, 0 runts, 0 giants
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0
    ignored, 0 abort
    15512 packets output, 4990958 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 babbles, 0 late collisions, 0 deferred
    0 lost carrier, 0 no carrier
    input queue (curr/max blocks): hardware (128/128)
    software (0/5)
    output queue (curr/max blocks): hardware (0/2)
    software (0/1)
    14922 aggregate VLAN packets input, 2610732 bytes
    15502 aggregate VLAN packets output, 4983666 bytes
    8629 vlan100 packets input, 996053 bytes
    9648 vlan100 packets output, 3560882 bytes
    0 invalid VLAN ID errors, 0 native VLAN errors

    interface vlan200 "dmz" is up, line protocol is up
    IP address 192.168.102.100, subnet mask
    255.255.255.0
    MTU 1500 bytes, BW 100000 Kbit full duplex
    505 packets input, 70930 bytes
    426 packets output, 65389 bytes

    interface vlan500 "vonage" is up, line protocol is up
    IP address 172.20.30.1, subnet mask 255.255.255.0
    MTU 1500 bytes, BW 100000 Kbit full duplex
    5788 packets input, 1543749 bytes
    5428 packets output, 1357395 bytes

    There are following NAT, ACL and Global policies in place:

    1. There is an ACL on outside interface (irrelevant)
    2. NO ACL on inside, DMZ and Vonage interfaces
    3. IP address of outside is defined for PAT for all interfaces
    4. There is NAT 0 accessing from internal interface to Dmz and Vonage
    interfaces

    access-list 130 permit ip 10.1.1.0 255.255.255.0
    192.168.102.0 255.255.255.0
    access-list 130 permit ip 10.1.1.0 255.255.255.0
    172.20.30.0 255.255.255.0

    nat (inside) 0 access-list 130
    nat (inside) 1 10.1.1.0 255.255.255.0 0 0
    nat (dmz) 1 192.168.102.0 255.255.255.0 0 0
    nat (vonage) 1 172.20.30.0 255.255.255.0 0 0

    global (outside) 1 interface



    Great. As I said, access to the internet form all logical interfaces
    works fine.

    Now let's access from inside network (Security zone 100, VLAN 100, IP
    - 10.1.1.0/24) to a workstation in DMZ (network. Here is the result:

    C:\Documents and Settings\Admin>ping 192.168.102.50

    Pinging 192.168.102.50 with 32 bytes of data:

    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    And in Pix's log we see following:

    106014: Deny inbound icmp src dmz:192.168.102.50 dst
    inside:10.1.1.100 (type 0, code 0)

    106014: Deny inbound icmp src dmz:192.168.102.50 dst
    inside:10.1.1.100 (type 0, code 0)

    106014: Deny inbound icmp src dmz:192.168.102.50 dst
    inside:10.1.1.100 (type 0, code 0)

    106014: Deny inbound icmp src dmz:192.168.102.50 dst
    inside:10.1.1.100 (type 0, code 0)

    There there is NO COMMUNICATION from higher security interface
    (Security100, VLAN100) to lower security interface (Security50,
    VLAN200).

    If I replace logical interface to physical, then everything will be
    fine. Also everything will be fine if I create ACL and apply it to the
    logical interface:

    access-list Dmz permit ip 192.168.102.0
    255.255.255.0 10.1.1.0 255.255.255.0 log
    access-list Dmz permit ip 192.168.102.0
    255.255.255.0 any a

    Access-g Dmz in interface Dmz

    But, could anybody explain me what is a point having logical
    interfaces if either I can't pass traffic between them? And to allow
    traffic from higher security interface to lower security interface I
    have to explicitly create ACL on lower security interface and as a
    result whole concept of separating networks makes no sense.

    Did I miss something?
     
    Irakli Natsvlishvili, Jul 18, 2004
    #1
    1. Advertising

  2. In article <>,
    Irakli Natsvlishvili <> wrote:
    :If I replace logical interface to physical, then everything will be
    :fine. Also everything will be fine if I create ACL and apply it to the
    :logical interface:

    :access-list Dmz permit ip 192.168.102.0
    : 255.255.255.0 10.1.1.0 255.255.255.0 log
    :access-list Dmz permit ip 192.168.102.0
    : 255.255.255.0 any a

    :Access-g Dmz in interface Dmz

    :But, could anybody explain me what is a point having logical
    :interfaces if either I can't pass traffic between them? And to allow
    :traffic from higher security interface to lower security interface I
    :have to explicitly create ACL on lower security interface and as a
    :result whole concept of separating networks makes no sense.

    :Did I miss something?

    You might have missed the part of the PIX 6.3 release notes that
    says that Adaptive Security handling of icmp is enhanced. But it still
    doesn't work as nicely as you might like. Having to create ACLs to
    permit responses to icmp echo is old hat for the PIX, and it's only
    in later 6.3 that you can *sometimes* get away without it.

    --
    We don't need no side effect-ing
    We don't need no scope control
    No global variables for execution
    Hey! Did you leave those args alone? -- decvax!utzoo!utcsrgv!roderick
     
    Walter Roberson, Jul 18, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ST MS

    PIX and VLANs

    ST MS, Dec 4, 2003, in forum: Cisco
    Replies:
    5
    Views:
    944
    Walter Roberson
    Dec 5, 2003
  2. ST MS

    PIX and VLANs continued

    ST MS, Jan 15, 2004, in forum: Cisco
    Replies:
    0
    Views:
    374
    ST MS
    Jan 15, 2004
  3. Replies:
    0
    Views:
    576
  4. punisher
    Replies:
    2
    Views:
    2,089
    Charles Deling
    Nov 17, 2005
  5. alsgto
    Replies:
    0
    Views:
    726
    alsgto
    Jul 18, 2006
Loading...

Share This Page