SOLVED
Hello,
Is Vlan-interface 1 the part of management access?
Thanks!
Hi @Rob_Dean !
From the configuration details provided it is hard to understand relation between Vlan-interface1 and GE1/0/1 (both are in 'trust') If the traffic that is dropped is flowing between those two interfaces, then it's expected. Packets between two interfaces that are in the same security zone are discarded by default. As well as traffic between interface in security zone and interface that is not in any zone:
If you want intra-zone traffic to be allowed by default, use the following command:
system-view
security-zone intra-zone default permit
If you need to allow traffic between different security zones, 'trust' and 'untrust' in your case, then you need to create a zone pair and allow the traffic you need explicitly as by default traffic between two interfaces in different security zones is not allowed.
Yes, it seems to be correct logic, but there is a catch.
Our configuration guides do not state it explicitly, but zone pairs are always uni-directional. If you check Fundamentals Configuration Guide for your router, you will see in the "Security zone configuration example" there is one feature called ASPF. It is not very obvious from the first glance why it is there in the zone pair configuration, so let me try to explain.
If you create just one zone-pair with source 'trust' and destination 'untrust' having an ACL applied, this will regulate ONLY traffic from 'trust' to 'untrust' zone, but not the one from 'untrust' to 'trust'. So if you ping a server on the Internet ('untrust') from a PC in 'trust' zone, then ICMP requests will be allowed (trust->untrust), but replies will be blocked, as 'untrust'->'trust' policy is not defined and traffic is discarded. Of course we can configure untrust->trust zone pair, but for many applications having two zone-pairs configs between each zone pair in order to regulate traffic in both direction is an akward solution. Here comes ASPF which basically is a stateful packet inspection and connection tracking mechanism. (FYI - There is predefined ASPF policy '1' and it inspects FTP packets and packets of all transport layer protocols, but it does not perform ICMP error message check or the TCP SYN packet check. but you can create more specific policies if you wish.)
So instead of having two zone-pairs - trust->untrust and untrust->trust, you can have only trust->untrust with ASPF applied. Of course you still need permissive ACL as well, because ASPF just tracks connections, but does not deny or permit traffic. So how it works - all outgoing packets from 'trust' to 'untrust' will be allowed by the ACL AND inspected by ASPF. ASPF will create state records for each allowed connection in the connection tracking database and when host on 'untrust' side will reply, this traffic will be allowed to the 'trust' zone, because firewall already knows it is just a reply to a traffic initiated (and allowed) from 'trust' zone. This is why in configuration examples you have ASPF.
However, if you want to be able to initiate traffic from 'untrust' to the 'trust' zone, like to have management access from the Internet to the router, then you will need to create zone pair with source 'untrust' and destination 'trust' and apply an ACL that will allow SSH/Telnet/HTTPS.
Summarizing:
So, to enable the zone firewall I need to do the following:
Add interface GigabitEthernet0/0 (WAN) to the untrust zone
YES
Add interface Vlan-interface1 (LAN) to the trust zone
CORRECT
Add a zone pair to allow traffic between the two
Sure, but it is more like this:
- Option A. You need to block all incoming traffic from 'untrust' to 'trust' if that is not a response to a traffic initiated previously from the 'trust' zone. In this case create 'zone-pair security source trust destination untrust', assign to it an ACL with 'rule permit ip' and assign ASPF policy 'aspf apply policy 1'. If you want custom policy, create it and then apply instead of '1'
- Option B. You need to block all incoming traffic from 'untrust' to 'trust' if that is not a response to a traffic initiated previously from the 'trust' zone, but there is one exception - incoming SSH/Telnet traffic must be allowed.
- Step 1. In this case create 'zone-pair security source trust destination untrust', assign to it an ACL with 'rule permit ip' and assign ASPF policy 'aspf apply policy 1'. If you want custom policy, create it and then apply instead of '1'
- Step 2. create 'zone-pair security source untrust destination trust', assign an ACL to the zone-pair that will permit explicitly the desired management protocol/-s.
Hope this helps!
Do you remember what was that IP address? Did it look like 169.254.x.x ?
If so, this was an automatically self-assigned IP address. If DHCP client can't get IP from DHCP server, it assignes to itself a random IP from 169.254.0.0-169.254.255.255 range... The question is why 'untrust' interface can't get IP from the ISP, since we technically have no inter-zone traffic here, no even intra-zone, the DHCP is initiated by Gig0/0 and terminated on the Gig0/0, everything stays inside the zone... Do you have any 'packet-filter' statements on the Gig0/0 itself?
Ok, I got it. It's been a long time since I played with ZBF on Comware routers, so that's probably why I overlooked one important point - there is a pre-defined zone 'Local' (actually 'Trust' and 'Untrust' are pre-defined as well) and when a traffic is initiated from the router, it goes from Local to another zone. So when Gig0/0 tries to send DHCP Request this packet technically goes from Local to Untrust. And of course you need a zone-pair for it. Also, you need zone-pair Untrust->Local in order to allow DHCP replies to get from ISP to your router. Here is a sample config in I've just tried in my lab, the Gig1/0 is my Untrust 'ISP' link:
security-zone name Untrust
import interface GigabitEthernet1/0
#
acl number 3000
rule 10 permit ip
#
acl number 3001
rule 10 permit udp source-port eq bootps
#
zone-pair security source Local destination Untrust
packet-filter 3000
#
zone-pair security source Untrust destination Local
packet-filter 3001
ACL 3001 is the one defines what traffic INITIATED from the Internet will be able to reach the router ITSELF. You can add 'rule 20 permit icmp' if you want your router to be pingable from the Internet. Pings initiated from the router work fine, so you don't need this line in order to get ICMP echo replies. Somehow it works even without ASPF, at least on my lab virtual VSR1000 router, on MSR1002 I can't test it.
BTW, this means that in order to keep SSH and/or Telnet session from Trust zone to the router you need "zone-pair security source Trust destination Local" with permissive packet-filter ACL applied. So technically when you SSH to Vlan-interface in 'Trust' zone even from the same interface (PC in the same Vlan) it is not Trust->Trust connection, it is Trust->Local.
Do you have zone-pairs with permissive ACLs defined for Local->Trust and Trust->Local? DHCP Server in the router should be inside the Local zone, so in order to communicate with local hosts in Trust zone you need two zone-pairs for each direction.