Forgive me if I have misunderstood anything.
The UTM support many tagged vlans, but only 16 when port based vlans are enabled as well, FYI.
The DMZ servers will use port forwarding for incoming HTTP/S and yes, with these VLAN's configured as DMZ, their access is restriced to the internet only as per below
From the online help
The Firewall Class determines the default firewall rules for packets sent or received on a network connection. These default rules can always be overridden using rules defined on the Packet Filtering page. The following describes each firewall class, and the default firewall rules for forwarded packets. Note that some services on the UTM Firewall unit will be accessible even if forwarded packets are dropped by default. For example, VPN services are accessible for any firewall class.
- Trusted local connection. All packets are accepted by default.
- Untrusted Internet connection. All packets are dropped by default.
- Untrusted local connection that provides services accessible from the Internet. Packets from DMZ to Internet connections are accepted, and all other packets are dropped by default. You will normally create Port Forwarding rules to allow packets from Internet to DMZ connections.
As Ross said, the switch we use on the devices have limits on the number of vlan tags they can track (which they need to if you are doing port-based vlans).
If you need more than a few segments, just leave A1-A4 as a single swtich (don't use port-based vlan) and then start adding vlans to that switch.
Sounds kind of dumb - you just told me not to use vlans then you tell me to add some. The important difference is the 'port-based' bit. By not using port-based
vlans you are leaving the little 4-port switch on the device ignorant of all the vlan tags you are using, so then you don't run into any limits.
Then you can add hundreds. it can of course be scripted...
Each vlan you create like this has its own independent firewall class so you can make it a DMZ, LAN, Internet or Guest.
Important thing to remember in setting up your switch is that you need the uplink (P1 in your example) to be a tagged member of all the vlans (100, 101, 102),
while your other ports need to all be untagged. So that looks a bit like a map with 'T' for tagged and 'U' for untagged
vlan 100 = P1(T), P2(U)
vlan 101 = P1(T), P3(U)
vlan 102 = P1(T), P4(U)
and of course you could add additional ports to the respective vlans.
What then happens is that as the packet leaves the CPU-NIC on its way to the 4-port switch on the device, it gets a 100 tag added (say).
As it arrives at P1 on your netgate its broadcast to all the members of vlan-100 (if its the first arp packet lets say). In your example that is just port P2. As P2 is an 'untagged' port, as the packet leaves P2, the netgate will strip the 100-vlan id off the packet, and then the piece of equipment that is plugged into P2 just sees a plain old ethernet frame that came from 192.168.100.1.
The response from the machine on P2 arrives at P2, gets vlan tag 100 added to it, then is broadcast (or its mac-destination looked up, say its for the mac of 192.168.100.1) goes out P1 with tag-100 firmly in place, back to the NIC on the UTM-CPU, where its correctly associated with the vlan-network-DMZ firewall rules you defined - and that's that.
So this is really handy if you want to partition your 48-port switch (or similar) into a bunch of security zones that have different firewall rules attached to them.
The downside is that you have to remember to keep the netgate switch configuration in sync with the UTM device.
Hope that helps.
I got a DNSproxy problem instead...
I set up each VLAN logical interface as "tagged" on port A4, and the other port as disabled as they are part of Switch A (A1, A2,A3)
Before I used untagged VLAN for access to a other network in the house (laserprinter and others stuff), this portbased VLAN have static IP, gateway and DNS configured worked as expected.
Normally this DNS entry was added last in the list of DNS servers in the Web UI, so I did take any notice of it (have using this for 3-4 years)
DNS: 184.108.40.206, 220.127.116.11, 18.104.22.168
But when I look in the diagnostic, this one 22.214.171.124 defined from VLAN103 seams to be the first one to answer.
Jan 27 09:53:54 dnsmasq: reading /etc/config/resolv.dnsmasq
Jan 27 09:53:54 dnsmasq: using nameserver 126.96.36.199#53
Jan 27 09:53:54 dnsmasq: using nameserver 188.8.131.52#53
Jan 27 09:53:54 dnsmasq: using nameserver 184.108.40.206#53
But somhow this DNS server does like me
Jan 27 09:53:53 dnsmasq: nameserver 220.127.116.11 refused to do a recursive query
These two other DNS servers is obtained from the DHCP client on Port B, 18.104.22.168, 22.214.171.124 (my internet access)
Perhaps this is uniqe for me, but why is the DNS server specified in other connection then the default gateway listed first?
There are a couple of things to note here.
First, because you specify port A4, you must have port based VLAN's enabled, and as such you must differentiate then from tagged VLAN's, and you will be limited to 16 in total, as already mentioned.
Secondly, DNS routing has changed...for a reason.
Recently many ISP's are refusing recursive queries from connections that are not their own customers. So the UTM device now sends DNS queries to upstream DNS servers using the specified link ONLY. If you have a DNS server specified across multiple links, all all links will carry traffic to this DNS server.
This should avoid any issues, such as the one you have.
So if I query the DNS server you mentioned in the logs ( and I am not a customer obviously )
rossco@moon:~$ dig @126.96.36.199 mcafee.com mx
; <<>> DiG 9.5.0-P2 <<>> @188.8.131.52 mcafee.com mx
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46670
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 6
;; WARNING: recursion requested but not available
I also get the same error and get no mx record returned...only ns servers so I can manually redirect my query there.
So to avoid the issue you have, make sure the DNS server 184.108.40.206 is ONLY specified under the link properties that relate to the relevant ISP.
And I would do the same for the other DNS servers you may have specified elsewhere to make sure you don't have other cases of this issue now, or in the future when your ISP disables this feature to non customers.
I have only specified 220.127.116.11 as DNS server on that specific VLAN103 link, the other two DNS entrys is something I get from my ISP as I use DHCP client on Port B (WAN)
Neverthenless this DNS 18.104.22.168 is used anyway for traffic that is going out on Port B (WAN) instead of only for traffic heading VLAN103.
I remember this was the same problem when I have multiple ISP, and used DHCP client for two of them, the resolv file was a combined list of booth of them.
1 of 1 people found this helpful
This should still work, even with multiple DHCP clients, as it is not the resolv.conf file that does the magic.
iptables routing does the magic via marks.
To see if it working correctly go to
network setup -> routes -> policy routes
and create a new rule
Type = OUTPUT
Destination Address = 22.214.171.124
Gateway = relevant link
What you put in here will override the magic routing that occurs under the hood and possibly identify if that is the issue
I am guessing the firewall class is not 'Internet' on that link.
No, that for sure. I changed to Internet, and it showed up. Why should not DMZ class interface be visable as well? I understand that this policy route is supposed to be used as a part of failover. However this was easly solved as I set this firewall class as Internet and failover destination as secondary.
The background story is that I have a ADSL connection 20/2 and private IP adress as I only get 5 DHCP assigned IP adresses from my ISP. I share my office with another company that have a SHDSL 2/2 line with a full class C adress, and they don't use NAT at all. My printers and PBX is hosted in thier network. And for me this network is a DMZ. So I want the traffic go strait to them
I added two policy routes then 1) a outgoing DNS policy for thier DNS and 2) forward 126.96.36.199/24 as well through same connection. works as expected.
Still my SG always resolve internet DNS through thier DNS server instead of my ISP DNS as my primary internet connection. Logical I would prefer that it uses my primary DNS servers rather my secondary connection DNS.
Jan 28 08:45:26 dnsmasq: reading /etc/config/resolv.dnsmasq
Jan 28 08:45:26 dnsmasq: using nameserver 188.8.131.52#53
Jan 28 08:45:26 dnsmasq: using nameserver 184.108.40.206#53
Jan 28 08:45:26 dnsmasq: using nameserver 220.127.116.11#53
I guess the SG access them in order.