03-26-2012 02:49 AM
We have problem which to routing between same trust zone under same virtual router - VR, only running different VLAN. Our envirnment setup is
184.108.40.206/28 - VLAN 10 - Zone: zone1
220.127.116.11/28 - VLAN 20 - Zone: zone1
Juniper already created new Sub-IF
ethernet0/3.10 - IP 18.104.22.168
ethernet0/3.20 - IP 22.214.171.124
I can see it already have route entry added to destination route
126.96.36.199/28 ethernet0/3.10 C Root
188.8.131.52/32 ethernet0/3.10 H Root
184.108.40.206/28 ethernet0/3.20 C Root
220.127.116.11/32 ethernet0/3.20 H Root
Switch already allowed VLAN 10 & 20 traffic
The strange thing is I have one machine example 18.104.22.168 can access and 22.214.171.124 by ping or ssh etc. But return was fail
Internet traffic can incoming/outgoing to zone1 by adding additional route at untrust zone with policy too.
Problem also appear in another trust zone: zone2 126.96.36.199/24 to access zone1 (zone2 --> zone1). However, zone1 --> zone2 did not such problem.
Did any way I can trace the problem? Thx!
03-26-2012 07:47 AM
If you have multiple interfaces (subinterfaces) connected to the same zone I would recommend to enable "Block intra-zone traffic" in the given zone and configure explicit intrazone access policies. If policy logging is enabled you can easiely find out what is running wrong.
Are zone1 and zone2 mapped to different VRs?
I do not recommend to use VLAN IDs for naming of the subinterfaces on the SSG. The number after the dot in the interface name is really a sequential number and not a VLAN ID, like on a Cisco device. If you SSGs supports twenty VLANS you will not be able to create the subinterface eth0/3.21. But you can create eth0/3.3 and assign VLAN tag 21 to it.
03-27-2012 09:28 AM
Policy logging will give you some information; if this doesn't give enough info, another option would be to run a debug (e.g. debug flow basic) to see exactly what's happening to the traffic step-by-step as it reaches and passes through the firewall.
KB article here
03-28-2012 02:01 AM
Tried to enable "block intra-zone traffic" and enabled log in policy. However noting log can record? Any idea?
Zone 1 and Zone 2 are under same VR now. Some additional information about Zone 1 & zone 2 is
Zone 2 is using ethernet0/3 and
Zone 1 is using ethernet0/3.x now
and I can see the Default IF of zone 1 is using ethernet0/3.10. Does it will affect the routing?
and Internet cand access Zone 1 without problems.
What is meaning of explicit intra zone access? This means create policy for in/out between zone 1 & zone 2? If yes, I have created those policy and enable logging too.
Thanks in advance.
03-28-2012 03:34 AM
Just find some message from debug log. It shall the traffic is route from
Zone 1 --> Zone 2
so that it did not match the policy under Zone 2 and its blacked. How it shoud be route .. Again my zone setting is
ethernet0/3 <-- Zone 2
ethernet0/3.10 <-- Zone 1
ethernet0/3.20 <--- zone 1
03-28-2012 05:32 AM
This is not a good idea to mix two VLANs with the native VLAN on the same trunk. I do not know how your switch is configured but can suppose that the packets from/to eth0/3 VLAN1 are dropped.
A good configuration might be (eg.):
ethernet0/3 - no IP, Zone Null
ethernet0/3.1 - VLAN tag 10, Zone 1
ethernet0/3.2 - VLAN tag 20, Zone 1
ethernet0/3.3 - VLAN tag xxx, Zone 2
The switch trunk port should transport VLANs 10,20 and xxx. You also need at least three access ports on the switch to connect at least three hosts, each to it's VLAN.
You asked: "What is meaning of explicit intra zone access? This means create policy for in/out between zone 1 & zone 2?"
The intrazone traffic flows from a zone to the same sone (eg. Zone 1 to Zone 1). If intrazone traffic is not blocked a default global policy is applied which is "Permit". If intrazone traffic is blocked the default global access policy is "Deny". In both cases this default policy does not appear in the policy ruleset (this means it is implicit). To control the intrazone traffic you should enable blocking and configure a couple of Zone 1 - to- Zone 1 policies.
If both zones are mapped to the same VR no additional static routes are required.
04-01-2012 10:04 PM
Thanks for all suggestion. It have solved after clean up all policy, VLAN subnet and rebuid it again. May be some missing in previously