Screen OS

last person joined: 8 months ago 

This is a legacy community with limited Juniper monitoring.
Expand all | Collapse all

Policy between sub interfaces

  • 1.  Policy between sub interfaces

    Posted 05-29-2010 11:24

    Hello,

     

    I created some sub interfaces on interface 0/4 with all different VLANs. They all exist in the default Trust zone. Interface 0/4 (from our SSG20) is connected to a switch where all these VLANs are connected using tagged ports. I now want to allow some traffic between VLANs and block other. The block intra-subnet traffic is enabled. How can I now create policies between these VLANs?

     

    Thanks



  • 2.  RE: Policy between sub interfaces

    Posted 05-29-2010 21:12

    With the intra-zone blocking setup for trust only traffic that you have created with specific intra-zone policy ( trust zone to trust zone ) will be allowed.  Any intra zone traffic that is not specifically allowed via the intra-zone policy will be dropped due to the intra-zone block.  

     

    So as far as needing to allow some traffic from vlan to vlan.  

     

    Create the specific address book entries for the trust zone to use as policy elements. Then create your specific intra-zone policy.  

     

    To allow vlan_1 to vlan_2 for example. 

     

    set address trust "vlan1" 10.1.1.0 255.255.255.0

    set address trust "vlan_2" 10.1.2.0 255.255.255.0

     

    set policy from trust to trust vlan_1 to vlan_2 http permit log

     

    The only thing you may want to do in your testing is to add a policy at the end of your policy chain to drop trust to trust traffic and log it.  While the intra-zone block will effectively do the same thing, the intra-zone block doesn't log.  During implementation of this you may want to add the ability to log for troubleshooting.   Just a thought.

     

     

    Hope this points you in the right direction.  

     



  • 3.  RE: Policy between sub interfaces

    Posted 05-30-2010 01:46

    Many thanks for your help, I was looking to far for the solution by creating different trusted zones and so on. Sometimes it can be simple 🙂

     

    A small problem I have is that my VLANs are all in the same subnet. I can not create rules for a full network segement as your example. Does this mean I need to create for every host a different rule or can I in some way specify the sub-interface or VLAN ID as filtering parameter?

    Also when I test it with two different segments (like 10.1.1.0 and 10.1.2.0) it works without any problem (policy to allow any to any at the moment), when I go to my final goal with one subnet (like 10.1.1.0 VLAN 4 and 10.1.1.0 VLAN 6) I can not get in any way a connection between both VLANs. It probably goes wrong at the routing side here as this is the same subnet. This is what was created by default.

     

    * 10.0.1.0/24   ethernet0/4.4 C     Root    -  => VLAN 4
    * 10.0.1.4/32   ethernet0/4.4 H     Root    -  => VLAN 4
    * 10.0.1.0/24   ethernet0/4.6 C     Root    -  => VLAN 6
    * 10.0.1.6/32   ethernet0/4.6 H     Root    -  => VLAN 6



  • 4.  RE: Policy between sub interfaces

    Posted 05-31-2010 00:29

    Hi,

     

    No, you cannot use the VLAN tag, nor subinterface as a policy element. You should try to describe the VLAN objects as groups of smaller networks and hosts. /25, /26, etc., and use this groups in the policies. This might be a cumbersome work, especially if the IP addressing schema is chaotic, f.i. .1 is located in VLAN 4, .2-in VLAN 6, .3 - again in VLAN 4 etc. It would be much easier if each VLAN is equal to a /25 or smaller network, or their sum. You can configure the allow-policies for certain hosts/groups and deny-policies for the VLAN-objects as trailing policies.

    An adequate naming convention for the objects is also very helpful.

     

    Kind regards,

    Edouard

     

     



  • 5.  RE: Policy between sub interfaces

    Posted 05-31-2010 04:46

    This is definately an odd situation and I have not tested this, but perhaps you could get the rules you need by assigning each of the vlans to a separate zone.

     

    • Create a zone for each vlan
    • assign the vlan to the named zone
    • write the rules between zones using the any option instead of creating network addresses

     

    Perhaps this will allow the overlapping subnets to be ignored and still apply the rules you want.



  • 6.  RE: Policy between sub interfaces

    Posted 05-31-2010 08:44

    I believe you are going to run into issues with basic networking and routing in this setup more than any concerns over policy elements and policy controls.  

     

    You have two subnets with the same IP network and netmask.  

     

    Because the destination will appear to the source as a local network it will never contact the default gateway ( sub-interface ) to move off local net.  It will arp for the address and try to contact the end node locally.  

     

    Operations off net for these two networks will also be impacted as destination traffic will have two connected networks with the same IP subnet info.

     

    Your best course of action is to take one of the subnets and re-address it so it is unique eliminating the issue.  

     

    As far as temp work arounds.  You could possibly separate the two vlans in separate virtual routers to provide routing isolation and use network address translation similar to the overlapping vpn examples that are found in the kb.  

     

     

    http://kb.juniper.net/kb/documents/public/ApplicationNotes/Technical/ScreenOS%204.0.0/IP-overlap-STATIC-NAT.htm



  • 7.  RE: Policy between sub interfaces

    Posted 06-02-2010 23:15

    The overlapping subnet gave to much problems. Therefore I re-address my network in smaller subnets as suggested each with its VLAN.

     

    Interface 0/4.1 VLAN 11: 10.0.1.1 / 27

    Interface 0/4.2 VLAN 12: 10.0.1.33 / 27

    Interface 0/4.3 VLAN 13: 10.0.1.33 / 27

    Interface 0/4.4 VLAN 14: 10.0.1.65 / 27

    Interface 0/4.5 VLAN 15: 10.0.1.97 / 27

    Interface 0/4.6 VLAN 16: 10.0.1.129 / 27

    Interface 0/4.7 VLAN 17: 10.0.1.161 / 27

    Interface 0/4.8 VLAN 18: 10.0.1.193 / 27

    Interface 0/4.9 VLAN 19: 10.0.1.225 / 27

    Interface 0/4: 10.0.2.1 / 23

     

    I blocked intra subnet traffic and created policies between them for the traffic allowed. When I now put a host in VLAN 11 I can ping without any problem to the network on interface 0/4. But it doesn't work between the VLANs. A trace route from a host in VLAN 11, for example 10.0.1.2 / SN: 255.255.255.224 / GW: 10.0.1.1 to VLAN 12, example 10.0.1.34 / SN: 255.255.255.224 / GW: 10.0.1.33 stops on the firewall. When I enable logging on the policy between the subnets I see messages "AGE OUT" for all the packets in between the subnets.

     

    The switch connected on Interface 0/4 has IP 10.0.2.2 / 255.255.254.0 / 10.0.2.1. The port connected to the firewall is set Tagging enabled for all the VLANs, for the hosts belonging to the VLAN I assigned Untagged to the port, all others, not belonging to the VLAN are set to Exclude. The hosts themselve have no VLAN ID assigned (already tested by assigning them one, but makes no difference).

     

    What is going wrong here. It looks like a basic routing issue, but the routes are there by default when creating the sub interfaces, also the interconnects between network 10.0.2.1 / 23 should have failed then.

     

    Thanks for your help.



  • 8.  RE: Policy between sub interfaces

    Posted 06-03-2010 00:00

    Hi,

     

    If you see "AGE OUT", then the request has been sent out of the subinterface but no response has arrived. This may also be a VLAN/trunk misconfiguration. In any case I would not recommend to mix tagged VLANs with the untagged one. Do not assign any IP to 0/4. It's better to create one more tagged VLAN for 10.0.2.1/23 and allow only tagged packets on the trunk. I would start the troubleshooting with analyzing of the MAC tables on the FW (get arp) and on the switch. "get flow basic" and "debug interface vlan" might also be helpful.

     

    Kind regards,

    Edouard



  • 9.  RE: Policy between sub interfaces

    Posted 06-03-2010 09:12

    I have assigned the 10.0.2.1 in a VLAN too now. No trunks are used, only one port on the switch is connected to the port 0/4 of the firewall, and all VLANs are set to tagged for this port.

     

    For what do I have to look for in these logs? I am not a firewall expert to understand all this debugging information.

     

    I have found something that I need to enable x802.1 to for inter VLAN routing. When I do this on the interface port 0/4 I get destination unreachables instantly.

     

    Connecting the internet from any of the VLANs is not an issue. It is really a connection between the VLANs on the same physical interface issue.



  • 10.  RE: Policy between sub interfaces

    Posted 06-03-2010 10:16

    I post the log that I collected because I think you will faster find anything usefull in it. This is how I collected it:

    1. debug interface basic

    2. set ff src-ip 10.0.14.34 (did not set any dst-ip)

    3. cl db

    4. started a ping on the server 10.0.14.34 (ethernet0/4.2 - VLAN 12) to 10.0.14.2 (ethernet0/4.1 VLAN 11)

    5. get db str

     

    ****** 00514.0: <Trust/ethernet0/4.2> packet received [60]******
      ipid = 4452(1164), @03911594
      packet passed sanity check.
      flow_decap_vector IPv4 process
      ethernet0/4.2:10.0.14.34/1500->10.0.14.2/1,1(8/0)<Root>
      no session found
      flow_first_sanity_check: in <ethernet0/4.2>, out <N/A>
      chose interface ethernet0/4.2 as incoming nat if.
      flow_first_routing: in <ethernet0/4.2>, out <N/A>
      search route to (ethernet0/4.2, 10.0.14.34->10.0.14.2) in vr trust-vr for vsd-                                                                             0/flag-0/ifp-null
      [ Dest] 5.route 10.0.14.2->10.0.14.2, to ethernet0/4.1
      routed (x_dst_ip 10.0.14.2) from ethernet0/4.2 (ethernet0/4.2 in 0) to etherne                                                                             t0/4.1
      policy search from zone 2-> zone 2
     policy_flow_search  policy search nat_crt from zone 2-> zone 2
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.0                                                                             .14.2, port 18303, proto 1)
      No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 27/0/0x9
      Permitted by policy 27
      No src xlate   choose interface ethernet0/4.1 as outgoing phy if
      no loop on ifp ethernet0/4.1.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_final_check: in <ethernet0/4.2>, out <ethernet0/4.1>
      existing vector list 1-43d1084.
      Session (id:7995) created for first pak 1
      flow_first_install_session======>
      route to 10.0.14.2
      arp entry found for 10.0.14.2
      ifp2 ethernet0/4.1, out_ifp ethernet0/4.1, flag 00800804, tunnel ffffffff, rc                                                                              1
      outgoing wing prepared, ready
      handle cleartext reverse route
      search route to (ethernet0/4.1, 10.0.14.2->10.0.14.34) in vr trust-vr for vsd-                                                                             0/flag-3000/ifp-ethernet0/4.2
      [ Dest] 7.route 10.0.14.34->10.0.14.34, to ethernet0/4.2
      route to 10.0.14.34
      arp entry found for 10.0.14.34
      ifp2 ethernet0/4.2, out_ifp ethernet0/4.2, flag 00800805, tunnel ffffffff, rc                                                                              1
      flow got session.
      flow session id 7995
      flow_main_body_vector in ifp ethernet0/4.2 out ifp ethernet0/4.1
      flow vector index 0x1, vector addr 0x20be308, orig vector 0x20be308
      post addr xlation: 10.0.14.34->10.0.14.2.
    ****** 00518.0: <Trust/ethernet0/4.2> packet received [60]******
      ipid = 4453(1165), @03913d94
      packet passed sanity check.
      flow_decap_vector IPv4 process
      ethernet0/4.2:10.0.14.34/1501->10.0.14.2/1,1(8/0)<Root>
      no session found
      flow_first_sanity_check: in <ethernet0/4.2>, out <N/A>
      chose interface ethernet0/4.2 as incoming nat if.
      flow_first_routing: in <ethernet0/4.2>, out <N/A>
      search route to (ethernet0/4.2, 10.0.14.34->10.0.14.2) in vr trust-vr for vsd-                                                                             0/flag-0/ifp-null
      [ Dest] 5.route 10.0.14.2->10.0.14.2, to ethernet0/4.1
      routed (x_dst_ip 10.0.14.2) from ethernet0/4.2 (ethernet0/4.2 in 0) to etherne                                                                             t0/4.1
      policy search from zone 2-> zone 2
     policy_flow_search  policy search nat_crt from zone 2-> zone 2
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.0                                                                             .14.2, port 18302, proto 1)
      No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 27/0/0x9
      Permitted by policy 27
      No src xlate   choose interface ethernet0/4.1 as outgoing phy if
      no loop on ifp ethernet0/4.1.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_final_check: in <ethernet0/4.2>, out <ethernet0/4.1>
      existing vector list 1-43d1084.
      Session (id:8051) created for first pak 1
      flow_first_install_session======>
      route to 10.0.14.2
      arp entry found for 10.0.14.2
      ifp2 ethernet0/4.1, out_ifp ethernet0/4.1, flag 00800804, tunnel ffffffff, rc                                                                              1
      outgoing wing prepared, ready
      handle cleartext reverse route
      search route to (ethernet0/4.1, 10.0.14.2->10.0.14.34) in vr trust-vr for vsd-                                                                             0/flag-3000/ifp-ethernet0/4.2
      [ Dest] 7.route 10.0.14.34->10.0.14.34, to ethernet0/4.2
      route to 10.0.14.34
      arp entry found for 10.0.14.34
      ifp2 ethernet0/4.2, out_ifp ethernet0/4.2, flag 00800805, tunnel ffffffff, rc                                                                              1
      flow got session.
      flow session id 8051
      flow_main_body_vector in ifp ethernet0/4.2 out ifp ethernet0/4.1
      flow vector index 0x1, vector addr 0x20be308, orig vector 0x20be308
      post addr xlation: 10.0.14.34->10.0.14.2.
    ****** 00523.0: <Trust/ethernet0/4.2> packet received [60]******
      ipid = 4454(1166), @03915d94
      packet passed sanity check.
      flow_decap_vector IPv4 process
      ethernet0/4.2:10.0.14.34/1502->10.0.14.2/1,1(8/0)<Root>
      no session found
      flow_first_sanity_check: in <ethernet0/4.2>, out <N/A>
      chose interface ethernet0/4.2 as incoming nat if.
      flow_first_routing: in <ethernet0/4.2>, out <N/A>
      search route to (ethernet0/4.2, 10.0.14.34->10.0.14.2) in vr trust-vr for vsd-                                                                             0/flag-0/ifp-null
      [ Dest] 5.route 10.0.14.2->10.0.14.2, to ethernet0/4.1
      routed (x_dst_ip 10.0.14.2) from ethernet0/4.2 (ethernet0/4.2 in 0) to etherne                                                                             t0/4.1
      policy search from zone 2-> zone 2
     policy_flow_search  policy search nat_crt from zone 2-> zone 2
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.0                                                                             .14.2, port 18301, proto 1)
      No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 27/0/0x9
      Permitted by policy 27
      No src xlate   choose interface ethernet0/4.1 as outgoing phy if
      no loop on ifp ethernet0/4.1.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_final_check: in <ethernet0/4.2>, out <ethernet0/4.1>
      existing vector list 1-43d1084.
      Session (id:8022) created for first pak 1
      flow_first_install_session======>
      route to 10.0.14.2
      arp entry found for 10.0.14.2
      ifp2 ethernet0/4.1, out_ifp ethernet0/4.1, flag 00800804, tunnel ffffffff, rc                                                                              1
      outgoing wing prepared, ready
      handle cleartext reverse route
      search route to (ethernet0/4.1, 10.0.14.2->10.0.14.34) in vr trust-vr for vsd-                                                                             0/flag-3000/ifp-ethernet0/4.2
      [ Dest] 7.route 10.0.14.34->10.0.14.34, to ethernet0/4.2
      route to 10.0.14.34
      arp entry found for 10.0.14.34
      ifp2 ethernet0/4.2, out_ifp ethernet0/4.2, flag 00800805, tunnel ffffffff, rc 1
      flow got session.
      flow session id 8022
      flow_main_body_vector in ifp ethernet0/4.2 out ifp ethernet0/4.1
      flow vector index 0x1, vector addr 0x20be308, orig vector 0x20be308
      post addr xlation: 10.0.14.34->10.0.14.2.
    ****** 00528.0: <Trust/ethernet0/4.2> packet received [60]******
      ipid = 4455(1167), @03916d94
      packet passed sanity check.
      flow_decap_vector IPv4 process
      ethernet0/4.2:10.0.14.34/1503->10.0.14.2/1,1(8/0)<Root>
      no session found
      flow_first_sanity_check: in <ethernet0/4.2>, out <N/A>
      chose interface ethernet0/4.2 as incoming nat if.
      flow_first_routing: in <ethernet0/4.2>, out <N/A>
      search route to (ethernet0/4.2, 10.0.14.34->10.0.14.2) in vr trust-vr for vsd-0/flag-0/ifp-null
      [ Dest] 5.route 10.0.14.2->10.0.14.2, to ethernet0/4.1
      routed (x_dst_ip 10.0.14.2) from ethernet0/4.2 (ethernet0/4.2 in 0) to ethernet0/4.1
      policy search from zone 2-> zone 2
     policy_flow_search  policy search nat_crt from zone 2-> zone 2
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.0.14.2, port 18300, proto 1)
      No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 27/0/0x9
      Permitted by policy 27
      No src xlate   choose interface ethernet0/4.1 as outgoing phy if
      no loop on ifp ethernet0/4.1.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_final_check: in <ethernet0/4.2>, out <ethernet0/4.1>
      existing vector list 1-43d1084.
      Session (id:7972) created for first pak 1
      flow_first_install_session======>
      route to 10.0.14.2
      arp entry found for 10.0.14.2
      ifp2 ethernet0/4.1, out_ifp ethernet0/4.1, flag 00800804, tunnel ffffffff, rc 1
      outgoing wing prepared, ready
      handle cleartext reverse route
      search route to (ethernet0/4.1, 10.0.14.2->10.0.14.34) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/4.2
      [ Dest] 7.route 10.0.14.34->10.0.14.34, to ethernet0/4.2
      route to 10.0.14.34
      arp entry found for 10.0.14.34
      ifp2 ethernet0/4.2, out_ifp ethernet0/4.2, flag 00800805, tunnel ffffffff, rc 1
      flow got session.
      flow session id 7972
      flow_main_body_vector in ifp ethernet0/4.2 out ifp ethernet0/4.1
      flow vector index 0x1, vector addr 0x20be308, orig vector 0x20be308
      post addr xlation: 10.0.14.34->10.0.14.2.

     



  • 11.  RE: Policy between sub interfaces

    Posted 06-04-2010 03:05

    Hi!

     

    This log confirms that the packets are correctly sent out through ethernet0/4.1. Is the backward route on 10.0.14.2 correct? Have you disabled the "ignore-subnet-conflict" enabled for the earlier tests? Please also check if the destination system sees the MAC address of the IP configured on ethernet0/4.1.

    Kind regards,

    Edouard



  • 12.  RE: Policy between sub interfaces

    Posted 06-04-2010 04:41

    Hello

     

    ignore subnet is now ticked OFF.

     

    How do I check that the route to 10.0.14.2 is correct? Should I apply another filter?

     

    The MAC addresses look ok on both interfaces, checked with ARP.

     

    Thank you so much for your help



  • 13.  RE: Policy between sub interfaces

    Posted 06-04-2010 04:46

    **** I have assigned the 10.0.2.1 in a VLAN too now. No trunks are used, only one port on the switch is connected to the port 0/4 of the firewall, and all VLANs are set to tagged for this port.

    ----------

     

    I think you may have a problem with this configuration to the switch port.  Your interface on the firewall is a tagged multiple sub interface trunk port.  You will need the switch port to be configured as a trunk port will all the same tagged vlans assigned to it.

     



  • 14.  RE: Policy between sub interfaces

    Posted 06-04-2010 05:09

    I have tried it with one trunk on the swicth. Meaning, all VLANs set TAGGED for the port connected to the firewall. And the ports connected to the hosts set Untagged in the VLAN where they belong too. This didn't change anything. The switch is a HP Procurve 1810, not must can be changed on it related to VLANs or Trunks, it is a very basic device.



  • 15.  RE: Policy between sub interfaces

    Posted 06-04-2010 09:59

    Hello,

     

    I made a few additional tests that may help in finding the solution:

     

    - ping from 10.0.14.2 (VLAN 11) to the gateway on the SSG 20 in VLAN 12: 10.0.14.33 works fine. This host can also ping its own gateway 10.0.14.1 (= SSG20).

    - ping from 10.0.14.34 (VLAN 12) to the gateway on the SSG 20 in VLAN 11: 10.0.14.1 works fine. This host can also ping its own gateway 10.0.14.33 (= SSG20).

    - on the switch I can ping both the 10.0.14.1 (GW of VLAN 11) and 10.0.14.33 (GW of VLAN 12).

     

    On the SSG 20 I can NOT ping the HOST in any VLAN (10.0.14.34 and 10.0.14.2), the same thing is true for the switch, unable to ping the hosts. The problem seems to be located on the switch as suggested by you before. The only problem is that I have no possibility to assign routes and configuration option are limited. Still I doubt that this "standard" setup is unable to work on this type of switch.

     

    Currently a static trunk is configured on the switch. Port 24, which is connected to the 0/4 interface of the firewall is set as TAGGED on all VLANs. For the rest het hosts belonging to the different subnets have UNTAGGED in case the port belongs to the VLAN or EXCLUDED in case it is not. It looks like the switch has not VLAN ID when the package comes back from the firewall. Any Ideas?



  • 16.  RE: Policy between sub interfaces

    Posted 06-04-2010 18:47

    I believe you have a configuration mismatch on the ports that are connecting the switch and the firewall.

     

    There are two port modes available for switching trunk and access.  When you want to connect a single set of ports to pass multiple vlans then they have to be setup as trunk ports.  Further they have to match in their trunk configurations.

     

    Switch

    On the switch set the port to trunk and include ONLY those vlan ids that you want to interconnect with the firewall.

    Remove all other vlan ids

    Do NOT include the untagged native vlan unless you are using this and also have it configured on the firewall.

     

    Firewall

    Create matching vlans with the same id on the firewall

    Create a sub interface on the connection port for each of these vlan ids so it matches exactly what you have configured on the switch



  • 17.  RE: Policy between sub interfaces

    Posted 06-05-2010 03:01

    When I understand your post well I have to say that this is already the case.

     

    I made the following changes:

    Interface 0/4 has now only two sub interfaces: 0/4.1 = 10.0.14.1/27 VLAN 11 and 0/4.2 = 10.0.14.33/27 VLAN 12. Same for the switch, only two VLANs exist, 11 and 12.

     

    The port 24 of the switch is connect to the firewall, this is the only port connecting to the firewall physically. It is a trunk set TAGGED in VLAN 11 and 12.

     

    The server with IP 10.0.14.2 on VLAN 11 is set UNTAGGED on port 11 of the switch. All other ports are set Excluded for VLAN 11. The Laptop with IP 10.0.14.34 on VLAN 12 is set UNTAGGED on port 1 of the switch. Again, all other ports are set Excluded for VLAN 12. The switch has IP 10.0.14.35. The subnet IDs are always 255.255.255.224 and the gateway for VLAN 11 is 10.0.14.1 and for VLAN 12 it is 10.0.14.33.

     

    With this setup I can ping the gateway for VLAN 11 - 10.0.14.1 from the 10.0.14.2 and for VLAN 12 - 10.0.14.33 from 10.0.14.34. As soon as I set the ports to TAGGED instead of untagged, I fail to ping the gateway IP. It looks like the conifguration on the tagged untagged is correct. It is also what I have found in the documantion from Procurve. Set the port unlinking to the Firewall as tagged an the ports connecting to host IN THAT VLAN to UNTAGGED. All other are Excluded.

     

    Note: there is a default VLAN1 on the firewall. It is impossible to remove it.

    Note2: there is a default VLAN1 on the switch, that is also impossible to remove.

     

    I am starting to think that I bought a switch model that is unable to handle the configuration I want, still I think it would be really strange, as it is not so special and uncommon what I do.



  • 18.  RE: Policy between sub interfaces

    Posted 06-05-2010 04:48

    This switching configuration is correct.  Access ports (where you plug in actual computers/printers) are untagged single vlan ports.  Only trunk ports use tags.  Tags are how the system is able to keep multiple vlan traffic segregated as they share the same wire path.  So these are only used during the trunking process.

     

    Just to confirm, is the vlan gateway configured on the firewall?  If so then all these connections are working.

    VLAN 11 - 10.0.14.1

    VLAN 12 - 10.0.14.33

     

    So the next step is to make sure the traffic between these vlans is allowed by policy.  From your earlier messages each vlan is in a different zone correct?

     

    Are there two zone to zone policies to permit traffic with logging enabled?

    vlan11zone to vlan12 zone permit all services any address

    vlan12zone to vlan11 zone permit all services any address

     

    If these are in place check logging and look at the log after you attempt the ping across vlans.



  • 19.  RE: Policy between sub interfaces

    Posted 06-05-2010 05:22

    Hi,

     

    Ping from 10.0.14.2 to:

    - 10.0.14.1 (gateway of VLAN 11): ok

    - 10.0.14.2 (it own IP): ok

    - 10.0.14.35 (switch mgt port  in VLAN 12): ok

    - 10.0.14.34 (laptop in VLAN 12): FAIL

    - 10.0.14.33 (gateway of VLAN 12): ok

     

    Logging on firewall:

     

    Traffic log for policy : ID Source Destination Service Action
    24Trust/10.0.14.0/27Trust/10.0.14.33/27ANYPermit
    2010-06-05 14:09:4410.0.14.2:3910.0.14.34:110.0.14.2:3910.0.14.34:1ICMP60 sec.820Close - AGE OUT
    2010-06-05 14:09:4010.0.14.2:3810.0.14.34:110.0.14.2:3810.0.14.34:1ICMP61 sec.820Close - AGE OUT
    2010-06-05 14:09:3610.0.14.2:3710.0.14.34:110.0.14.2:3710.0.14.34:1ICMP61 sec.820Close - AGE OUT
    2010-06-05 14:09:3210.0.14.2:3610.0.14.34:110.0.14.2:3610.0.14.34:1ICMP62 sec.820Close - AGE OUT
    2010-06-05 14:09:0010.0.14.2:4310.0.14.33:110.0.14.2:4310.0.14.33:1ICMP3 sec.8282Close - RESP
    2010-06-05 14:09:0010.0.14.2:4210.0.14.33:110.0.14.2:4210.0.14.33:1ICMP4 sec.8282Close - RESP
    2010-06-05 14:08:5810.0.14.2:4110.0.14.33:110.0.14.2:4110.0.14.33:1ICMP3 sec.8282Close - RESP
    2010-06-05 14:08:5810.0.14.2:4010.0.14.33:110.0.14.2:4010.0.14.33:1ICMP4 sec.8282Close - RESP
    2010-06-05 14:08:2610.0.14.2:3510.0.14.35:110.0.14.2:3510.0.14.35:1ICMP4 sec.8282Close - RESP
    2010-06-05 14:08:2410.0.14.2:3410.0.14.35:110.0.14.2:3410.0.14.35:1ICMP3 sec.8282Close - RESP
    2010-06-05 14:08:2210.0.14.2:3310.0.14.35:110.0.14.2:3310.0.14.35:1ICMP2 sec.8282Close - RESP
    2010-06-05 14:08:2210.0.14.2:3210.0.14.35:110.0.14.2:3210.0.14.35:1ICMP3 sec.8282Close - RESP
     

     

    Ping from 10.0.14.34 to:

    - 10.0.14.33 (gateway of VLAN 12): ok

    - 10.0.14.34 (it own IP): ok

    - 10.0.14.35 (switch mgt port  in VLAN 12): ok

    - 10.0.14.2 (server in VLAN 11): FAIL

    - 10.0.14.1 (gateway of VLAN 11): ok

     

    Logging on firewall:

     

    Traffic log for policy : ID Source Destination Service Action
    25Trust/10.0.14.33/27Trust/10.0.14.0/27ANYPermit
    2010-06-05 14:14:5610.0.14.34:1610.0.14.2:110.0.14.34:1610.0.14.2:1ICMP61 sec.820Close - AGE OUT
    2010-06-05 14:14:5210.0.14.34:1510.0.14.2:110.0.14.34:1510.0.14.2:1ICMP62 sec.820Close - AGE OUT
    2010-06-05 14:14:4610.0.14.34:1410.0.14.2:110.0.14.34:1410.0.14.2:1ICMP61 sec.820Close - AGE OUT
    2010-06-05 14:14:4210.0.14.34:1310.0.14.2:110.0.14.34:1310.0.14.2:1ICMP62 sec.820Close - AGE OUT
    2010-06-05 14:14:0810.0.14.34:1910.0.14.1:110.0.14.34:1910.0.14.1:1ICMP4 sec.8282Close - RESP
    2010-06-05 14:14:0610.0.14.34:2010.0.14.1:110.0.14.34:2010.0.14.1:1ICMP1 sec.8282Close - RESP
    2010-06-05 14:14:0610.0.14.34:1810.0.14.1:110.0.14.34:1810.0.14.1:1ICMP3 sec.8282Close - RESP
    2010-06-05 14:14:0610.0.14.34:1710.0.14.1:110.0.14.34:1710.0.14.1:1ICMP4 sec.8282Close - RESP


  • 20.  RE: Policy between sub interfaces

    Posted 06-05-2010 05:33

    It appears that these vlan11 and vlan12 are in the same zone.

     

    I think you have block intra zone traffic turned on for trust.  This appears to be stopping the communications.  If you need full access between hosts in the same zone you will need this turned off.

     

    You should have these in two different zones with policies iif you need to control traffic.  But since you are looking for full access between the vlans then just having them in the same zone without blocking is fine.  If your server zone will only allow certain traffic in the future put them in different zones and create the two cross zone policies.



  • 21.  RE: Policy between sub interfaces

    Posted 06-05-2010 05:43

    I have set the Intra subnet blocking on both VLANs to OFF to test it. Same result as my previous post.

     

    The final goal is to have blocking of traffic between the subnets enabled, but for some traffic it must be allowed to interconnect between VLANs. DNS server is located in a management LAN that is shared for all VLANs. In this management VLAN other servers exist and these should NOT be reachable from the different VLANs.



  • 22.  RE: Policy between sub interfaces

    Posted 06-05-2010 05:48

    Sorry for the confustion.  I'm talking about the Zone "Trust" not the vlan.

     

    The log indicates that both segments are in the "Trust" zone.  I believe the zone settings have "block intra-zone traffic" enabled for trust.

     

    Web UI

    Network--zones

    Edit trust zone



  • 23.  RE: Policy between sub interfaces

    Posted 06-05-2010 06:04

    Hi,

     

    Also on the Zone "Trust" it is NOT enabled (checked off).

     

    I moved the VLANs to seperated LEVEL 3 zones. Created policies between then, without succes:

     

    Traffic log for policy : ID Source Destination Service Action
    28VLAN12/10.0.14.33/27VLAN11/10.0.14.0/27ANYPermit
    2010-06-05 15:01:5110.0.14.34:32610.0.14.2:110.0.14.34:32610.0.14.2:1ICMP61 sec.820Close - AGE OUT
    2010-06-05 15:01:4710.0.14.34:32510.0.14.2:110.0.14.34:32510.0.14.2:1ICMP62 sec.820Close - AGE OUT
    2010-06-05 15:01:4110.0.14.34:32410.0.14.2:110.0.14.34:32410.0.14.2:1ICMP61 sec.820Close - AGE OUT

     

    Traffic log for policy : ID Source Destination Service Action
    27VLAN11/10.0.14.0/27VLAN12/10.0.14.33/27ANYPermit
    2010-06-05 15:02:5910.0.14.2:20710.0.14.34:110.0.14.2:20710.0.14.34:1ICMP62 sec.820Close - AGE OUT
    2010-06-05 15:02:5310.0.14.2:20610.0.14.34:110.0.14.2:20610.0.14.34:1ICMP60 sec.820Close - AGE OUT
    2010-06-05 15:02:4710.0.14.2:20510.0.14.34:110.0.14.2:20510.0.14.34:1ICMP59 sec.820Close - AGE OUT
    2010-06-05 15:02:4310.0.14.2:20410.0.14.34:110.0.14.2:20410.0.14.34:1ICMP60 sec.820Close - AGE OUT

     



  • 24.  RE: Policy between sub interfaces
    Best Answer

    Posted 06-05-2010 06:14

    Any chance the windows firewall is turned on?

     

    Can you ping the switch mgmt interface from the firewall vlan interface.

     

    Log into console on firewall

    ping 10.0.14.35 from vlan11



  • 25.  RE: Policy between sub interfaces

    Posted 06-05-2010 06:22

    Many many thanks, The windows firewall was the clue. I had set it off in earlier tests but reenabled it again later. I am so happy that it is finally solved!



  • 26.  RE: Policy between sub interfaces

    Posted 06-05-2010 06:25

    I'm glad you have it working.  I know how frustrating it can be when things don't.