https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js

Guest network configuration

In this post we will configure an SRX firewall for Guest access. We will create the interfaces, policies and basic dhcp and dns services.

Guest networks

Guest networks are networks in your company to provide network access for devices not managed by your company.

You want to be hospitable to guests who visit your company, or maybe provide access for bring your own devices from your colleagues, but in a secure way.

You don’t want to give free access from your guest networks to your production or business environment.

Our article will be limited to configuring the SRX for Guest access. We will configure the interfaces, zones, policies, dns forwarder and dhcp service. We will not explain how to configure your wireless or your voucher system in this article.

Network

We will need to separate the guest traffic from our production traffic. This means we need VLANs for Guest access. For Wireless access you can provide a special Guest SSID which will connect to your Guest VLAN. For wired network access you can either provide dedicated Guest connections or use a UAC solution to automatically assign Guest access for unauthenticated devices.

Internet access

However it is possible to share your internet connection between your production traffic and guest traffic, I would recommend to provide a dedicated internet connection for Guest access. Your production internet connection is probably a more expensive connection with guaranteed bandwidth and SLA’s. Why waste (expensive) bandwidth to provide guest internet access? You can just provide a residential internet connection for your Guest users, it will be fast enough and the SLA’s are not required.

Services

A network doesn’t run without some basic services. You will need a router, a dhcp server and a DNS server. The router will be our security device. For the dhcp server and dns server we could use your production services. However I would advise against this. I would recommend to use a DHCP server on a security device and to configure a DNS proxy on your security device. As a forwarder you could use public dns servers or the dns server of your ISP.

Configuration

Interface

We will need to configure an interface for guest access. Let’s keep it easy and just configure one /24 network to start:

interfaces {
    ge-0/0/3 {
        description "Guest Network";
        unit 0 {
            family inet {
                address 172.16.10.1/24;
            }
        }
    }
}

We will also need to add an interface to our internet connection. In this example the ip address will be provided via dhcp.

interfaces {
    ge-0/0/1 {
        description "Guest internet connection";
        unit 0 {
            family inet {
                dhcp-client;
            }
        }
    }
}

Security zone

We need to put our interfaces in a security zone before it will start to work. We also will need to allow some host inbound services.

Guest interface

Host inbound traffic is for the DHCP. Normally I would also add dns for the dns forwarding. However I stumbled on a problem where the dns forwarding only works in the default routing table. I will explain further on what the problem is and how we can solve it with a dirty workaround.

security {
    zones {
        security-zone guest {
            interfaces {
                ge-0/0/3.0 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                        }
                    }
                }
            }
        }
    }
}

Internet interface

Since I’m using DHCP for my internet facing interface, I need to open up the SRX for dhcp. System service for dhcp are required. Otherwise the SRX will drop incoming DHCP reply’s. If you are configuring your SRX for static configuration this is not required. If you need to use BGP you also need to configure a system service for BGP. Otherwise it will also be dropped.

We also need to make a special zone for our Guest internet interface. If we would use an existing untrust interface we would have a commit error.

[edit security zones security-zone untrust]
  'interfaces ge-0/0/1.0'
    Interface ge-0/0/1.0 must be in the same routing instance as other interfaces in the zone
error: configuration check-out failed

So we will create a zone with the name “untrust-guest”

security {
    zones {
        security-zone untrust-guest {
            interfaces {
                ge-0/0/1.0 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                        }
                    }
                }
            }
        }
    }
}

Routing instance

Since we have multiple internet connections and we want to separate production traffic and guest traffic we will create a routing instance just for Guest access. We will put our internet interface and the guest interface in this new routing instance. I will call it “GUEST”.

Update: It’s also possible to dedicate a firewall just for your Guest solution, then this config is kinda irrelevant unless you like to run all traffic in routing-instances. Running all your traffic in routing-instances is what you need to do when you want to use your management interface, since it will pop up in the routing table (in Junos).

routing-instances {
    GUEST {
        instance-type virtual-router;
        interface ge-0/0/1.0;
        interface ge-0/0/3.0;
    }
}

If you are using static configuration for your routing or bgp, you also need to configure this in the routing instance. I will include an example for static configuration, this is normally not required with DHCP, because the DHCP server will usually provide you with a default gateway.

routing-instances {
    GUEST {
	    routing-options {
            static {
                route 0.0.0.0/0 next-hop 1.1.1.1;
            }
        }
    }
}

DHCP server

So obviously we don’t want to provide static addresses to all our clients. We want them to get an address automatically. For this we will to push some parameters with DHCP. I already wrote an article about DHCP. You can find it here. However here we want to run a server inside a routing instance.

So we will need to enable the service and appoint the right interface. To that nameserver parameter I will be coming later. Normally it would be the address of the ge-0/0/3.0 interface. But since there is a problem with the dns forwarding only working on the default routing table, I had to change the config a bit. I will get to that later.

routing-instances {
    GUEST {
        instance-type virtual-router;
        system {
            services {
                dhcp-local-server {
                    group guestdhcp {
                        interface ge-0/0/3.0;
                    }
                }
            }
        }
        access {
            address-assignment {
                pool guestpool {
                    family inet {
                        network 172.16.10.0/24;
                        range guestrange {
                            low 172.16.10.10;
                            high 172.16.10.200;
                        }
                        dhcp-attributes {
                            name-server {
                                10.66.66.1;
                            }
                            router {
                                172.16.10.1;
                            }
                        }
                    }
                }
            }
        }
        interface ge-0/0/1.0;
        interface ge-0/0/3.0;
    }
}

DNS Proxy

So we want to configure a dns proxy on the SRX. Apparently this works only in the default routing instance. I didn’t check on the latest versions of Junos. If I can get it to work I will update the article.

Anyway, as a work around I made a loop between the default routing-instance and the guest routing-instance. For this loop I used an lt interface. Which is a “logical tunnel” interface. It can be used on SRX as well as on MX devices.

It’s a virtual link between those two routing instances. We will need to put those interfaces in security zones and configure policies. Because traffic will go through the SRX (through that lt interface).

Interfaces

Configuration of the lt interfaces. The lt interfaces can only be point to point and you need reference the other side of the tunnel with the “peer-unit” statement. In our situation the ethernet encapsulation will be sufficient. Other encapsulation types are available.

interfaces {
    lt-0/0/0 {
        unit 1 {
            description dns-tunnel;
            encapsulation ethernet;
            peer-unit 2;
            family inet {
                address 10.66.66.1/30;
            }
        }
        unit 2 {
            description dns-tunnel;
            encapsulation ethernet;
            peer-unit 1;
            family inet {
                address 10.66.66.2/30;
            }
        }
    }
}

Security zones

We need to put our two interfaces in security zones. The interface from the default routing instance (lt-0/0/0.1) also needs to allow incoming dns requests. Since here we will run our dns forwarder. The interface fom the Guest VR does not need to allow any services.

security {
    zones {
        security-zone dns-prod {
            interfaces {
                lt-0/0/0.1 {
                    host-inbound-traffic {
                        system-services {
                            dns;
                        }
                    }
                }
            }
        }
        security-zone dns-guest {
            interfaces {
                lt-0/0/0.2;
            }
        }
    }
}

Policy

As mentioned before we need to allow dns to flow through the SRX. I also made an address object to make the policy more specific. The source I kept to any, because we might need to add more source addresses in the future and I don’t see a big risk in allowing access to all for the dns forwarding.

security {
    zones {
        security-zone dns-guest {
            address-book {
                address dns-forwarder 10.66.66.1/32;
            }
            interfaces {
                lt-0/0/0.2;
            }
        }
    }
    policies {
        from-zone guest to-zone dns-guest {
            policy allow-dns {
                match {
                    source-address any;
                    destination-address dns-forwarder;
                    application [ junos-dns-tcp junos-dns-udp ];
                }
                then {
                    permit;
                }
            }
        }
    }
}

Routing/Natting

If you are testing this configuration, you will notice it doesn’t work yet. Why? Well let’s check the routing table of the default VR.

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0          *[Access-internal/12] 00:59:18
                    > to 172.20.10.1 via ge-0/0/0.0
10.66.66.0/30      *[Direct/0] 00:59:24
                    > via lt-0/0/0.1
10.66.66.1/32      *[Local/0] 00:59:24
                      Local via lt-0/0/0.1
172.20.10.0/28     *[Direct/0] 02:19:59
                    > via ge-0/0/0.0
172.20.10.5/32     *[Local/0] 02:19:59
                      Local via ge-0/0/0.0
192.168.200.0/24   *[Direct/0] 02:22:10
                    > via ge-0/0/2.0
192.168.200.1/32   *[Local/0] 02:22:12
                      Local via ge-0/0/2.0

So, the route to our guest network is missing (172.16.10.0/24). Traffic coming from this network to the default VR will flow to the default route and not back to the lt-0/0/0.2 interface. So there are 2 ways of fixing this: or we add a route in the default VR, or we apply source natting.

For this example I choose to configure source natting. This makes it easier to add more subnets in the guest zone later. However you could also choose to add routes in the Default VR.

Be carefull with this configuration, cause you are actually opening your default VR to Guest (untrust) users and devices. This is actually against the idea of separation of the virtual router. But since we have the limitation of the dns forwarder, I don’t think there is another way to do this (if there is, please let me know).

security {
    nat {
        source {
            rule-set GUEST {
                from zone guest;
                to zone dns-guest;
                rule s-nat {
                    match {
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
}

The resolving should work now. But we still don’t have internet access. We need to create source natting for going to the internet and we need a policy to allow us to the internet.

Source NAT and Policy

We already created a source nat rule in the previous step. We will just need to add a zone to that configuration.

The SRX will use the address of the outgoing interface as the source address of the IP packet.

security {
    nat {
        source {
            rule-set GUEST {
                from zone guest;
                to zone [ dns-guest untrust-guest ];
                rule s-nat {
                    match {
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
}

Traffic flow:

Traffic will flow as on following scheme. We need a policy for this for the SRX to allow it to pass.

Policy:

I made a quiet open policy. Just limiting the applications. Of course you can configure the rulebase to your needs.

security {
    policies {
        from-zone guest to-zone untrust-guest {
            policy allow-internet {
                match {
                    source-address any;
                    destination-address any;
                    application [ junos-http junos-https junos-dns-udp junos-dns-tcp junos-icmp-all ];
                }
                then {
                    permit;
                }
            }
        }
    }
}

It might also be a good idea to configure some screen options for your guest zones. Just to protect the SRX (maximum amount of session for example). I’m not very experienced with the best practices of this. So I might figure this out in a later article.

Conclusion

We made a guest network in a separate virtual router. We configured a dhcp server in this virtual router and we provided a dns forwarder. We also made policies to access this dns forwarder and to access the internet. And we created source natting rules to translate our traffic.

This is what I think is the minimal that is needed for a Guest zone configuration.
There are of course different strategies possible. You could for example use a separate firewall for your Guest configuration, or provide a dedicated server for DNS and DHCP services. It’s all a matter of choise and possibilities.

Thanks for reading and please comment how you would configure your guest zone.

Leave a Reply