04-21-2012 06:33 AM
I need to put a new server on the network, which needs to have a public IP-address. The supplier of this SIP-server insist on having one of the server interfaces configured with a public routable IP-address, so a MIP is not an option.
Our setup is quite straightforward. We have a SSG5 connected to a switch on a /27 network with a couple of IP-addresses available to us:
eth0/1 Untrust x.x.x.156 / 27 with gateway x.x.x.129 / 27 and a couple of VIP's on x.x.x.157
eth0/2 DMZ 192.168.4.0 / 24
The public address of the new SIP-server is x.x.x.155 / 27, which is in the same subnet as the Untrust interface of the SSG5. A second interface of this server needs to be put in our DMZ. Audio streams are going to be routed through the SIP-server to codecs in the DMZ zone.
Of course I don't want to have this server unprotected on the internet. But if I put it on another interface of the SSG5 I get the overlapping subnet error.
The only solution I can think of is a second firewall put in transparent mode to protect the SIP-server.
But is there another way of doing this on one SSG?
Any input is greatly appreciated!
04-21-2012 11:07 AM
You can move your eth0/1 ip address to a bgroup and then have eth0/1 and another interface for your sip server assigned to this bgroup.
Intrazone blocking is enabled by default for the untrust zone. So you will then need to create the necessary policies for what untrust traffic is allowed to forward to the sip server.
The inbound traffic will arrive from the isp line that I assume you have connected to eth0/1 and be forwarded to the sip server on the second interface if there is a policy that allows the traffic.
I've noticed that when voip vendors want to directly connect their server, it usually means they have no idea how to identify and allow their specific traffic. So you may end up with issues initially in connections to troubleshoot.
You will probably need to create a custom service and assign this to "application sip" in your policy to allow the random ports that negotiate for the call sessions. This is usually the "problem" with putting the public interface behind a nat firewall and not the address translation itself.
04-21-2012 02:11 PM
Thank you for your answer. But as far as I understand a bridge group puts the interfaces that are members of this bgroup in the same broadcast domain. Wouldn't traffic be switched between these two interfaces regardless of the security settings?
04-21-2012 03:16 PM
Yes, the bgroup does put the interfaces into the same broadcast domain. But the configuration of the zone still applies to the traffic for that zone of the bgroup.
By default, all zones allow traffic between nodes in the same zone freely. The exception is the untrust zone. This one does have the intrazone blocking parameter set. So the default behavior without any intrazone policies will be to block traffic for untrust to untrust traffic.
Intrazone blocking can be turned on for any zone as needed.
Generally the trick is getting the traffic between two nodes in the same zone to transit the firewall so it can apply the block policy. That is why the bgroup is needed in these cases. You need both the inbound isp traffic to arrive on one firewall interface and need to forward it out a second on the firewall so it has the opportunity to do the policy lookup. With the zone being untrust and therefore intrazone blocking turned on this will work for you.
Your policies are then untrust to untrust for this traffic.
04-23-2012 04:49 AM
04-23-2012 12:05 PM
I'm afraid the setup with a bgroup on the untrust side doesn't work. I did a test setup on a SSG5 with 2 interfaces put in a bgroup. I've put this bgroup in the Untrust zone and put an IP-address on it. Everything else is setup in a basic manner. Just one policy allowing all traffic from Trust to Untrust. Intra-zone blocking on the Untrust zone is in place. But if i put a host on the second untrust interface it immediately gets an IP-address from the DHCP server from the upstream router and can access the internet. So despite of the fact that intra-zone blocking is enabled and there isn't any policy from untrust to untrust, traffic is flowing freely between these 2 interfaces. It is just acting like a switch.
So I have to find another solution for my problem...
04-23-2012 03:37 PM
Obviously I'm surprised the intrazone blocking does not work with a bgroup. I use this a lot in untrust for other interfaces.
I have another possibility you could test. I did a partial implementation in a lab last year and this worked as far as I tested. But it ended up not being something I pursued.
I used two virtual routers to mix transparent mode with layer 3 on the same device. The trick was that the transparent vr had to be trust-vr as it would not let me move the vlan1 interface and zone.
I was able to have the second vr function as a normal layer 3 firewall and insert the trust-vr transparent mode interfaces into a server connection.
But the testing was short lived and limited. I ended up abandoning the approach for the intrazone blocking design.
04-23-2012 03:53 PM
I tested the bgroup blocking on an SSG-140, and it didn't yeild good results either -- traffic was not blocked. The bgroup member ports acted as if they were part of a switch external to the firewall. I have a feeling that's not intended behavior, but that's what happens.
I did also test the hack I mentioned earlier. It works fine, but not quite as elegantly as on a Cisco router, and in fact is quite a bit of a kludge as it requires specific configuration on the DMZ server itself. I would say it can be used, but as a last resort. I amended the steps as following:
1) Configure server as if there's no firewall (public IP, default gw is ISP router)
2) Connect server to DMZ interface.
3) Configure static ARP on the DMZ server: ISP GW IP -> MAC of DMZ interface on FW. Unfortunately, the firewall refuses to do Proxy ARP on an interface for IP that doesn't belong to that interface. That is a bummer.
3) Set up /32 static route for the server IP going out of the DMZ interface (no gw address). The route must have a preference of 0. That's so that it's on par with Connected routes.
4) Enable proxy ARP for the DMZ Server IP address on the Unturst interface.
5) Set up Untrust<->DMZ policy for policies to allow traffic in and out as necessary.
6) The DMZ interface must have an IP address configured. If you already have a DMZ subnet defined, then that's fine. Otherwise, any IP address will do (even a /32), because the firewall will not route traffic out of an interface if that interface has no IP address (even if a route appears as active in the routing table).
05-10-2012 11:15 AM
Why would that not be the intended behavior for a bgroup? Your not traversing "interfaces" at that point. If you have eth0 and eth1 both in the untrust zone, your traversing interfaces, and subnets so policy can be applied.
By first question really is.... why is the SIP provider so insistant on not using a MIP. Also, have you tried to get away with it? They might never know, perhaps it's just because they don't like dealing with tshooting through a firewall?