08-01-2012 07:27 PM
My current set up is an SSG20 with an adsl interface and VPN tunnel to head office (where our DNS servers are located). DNS on the SSG is set with the DHCP section pointing to our internal DNS servers, therefore taking all traffic through the tunnel.
The DNS section itself is not configured on the SSG.
I'd like to redirect traffic to certain websites via the untrust interface so they are not hitting the VPN tunnel. What would be the best way of attacking this?
Thanks in advance..
Solved! Go to Solution.
08-01-2012 11:51 PM
DNS resolution has nothing to do with routing. If you route all Internet traffic into the tunnel using a default route, the only way to reach certain web servers directly through Untrust interface are the static routes for their IPs. The host and network routes take precedence over the default route.
08-02-2012 05:05 AM
Are all web traffic passing over the VPN tunnel?
As Edouard mentioned, you can create a specific /32 host routes for the web sites and set the next hop out the untrust interface.
Alternatively, policy-based routing may also work in this situation.
08-02-2012 08:29 PM
Thanks for your replies. Sorry, after looking into it a bit further, I gave you some incorrect info. Only internal traffic to the head office goes over the vpn, however, the site they want is also available internally so they are connecting using internal ip.
It's basically too slow over the vpn so I'd like to fire it out via the external. I won't be able to route the internal ip out as it won't resolve. Their DNS will resolve the site as the internal ip. Is there a way to catch traffic going to that ip/hostname and redirect it out of the external?
08-03-2012 12:14 AM
The simplest solution is to enable DNS Proxy on Trust interface and create a couple of static cache entries for these web servers which are mapped to the public IPs (Network -> DNS -> Cache). The firewall itself should be able to resolve DNS requests using the internal DNS server (Network -> DNS -> Host). The option Network -> DNS -> Host->Show DNS Lookup Table can be used to check/troubleshoot the DNS name resolution.
A complexer solution would be Proxy DNS Address Splitting (Vol. Fundamentals. C&E). This solution is more flexible. But if you need to resolve certain DNS requests to the public IPs and others to the internal IPs, while both groups of IPs are mapped to the same domain, this solution might become too complex.
08-03-2012 06:16 AM
08-05-2012 08:23 PM
Yes that's exactly what I want to do with the least amount of changes. I'm not currently using PBR so is it pretty straightforward to configure?
08-06-2012 12:43 AM
PBR is not simple and, what is more, it does not solve your problem without NAT. But if you have configured a NAT PBR is not required...
Yes, you can translate the private IPs of your internal services to their public IPs on Trust interface, using eg. MIPs.
08-06-2012 04:27 PM - edited 08-06-2012 04:53 PM
Thanks for that. So, I've set up a MIP entry on the Bgroup trust interface and set the mapped ip to the internal address and the host IP to the external ip that i want to reroute to. Netmask I've selected as 255.255.255.255 as it's just the one ip and host vr name is untrust.
I checked the access policy list too, and allowed any-any from trust-untrust. I'm still have no luck, it just doesn't connect now. I'm clearly missing something?
08-07-2012 12:00 AM
If you did not change default zone-to-vr mappings the Untrust zone is mapped to the Trust-vr. This means that the host vr is Trust-vr. The rule is simple - the host vr is the one that the destination zone and the egress interface are mapped to.
This policy will not work. The MIP and VIP objects do not belong to the object Any in any zone besides Global zone. The policy should be any-to-MIP (or LANaddress-to-MIP). Do not mix MIP with other objects in the policy! If ScreenOS finds a MIP (multiple MIPs) in a policy it interprets this policy as a Source zone -> Global zone policy. Essentially, this plays no role which zone is used as the destination one if the policy contains MIPs and VIPs. But people prefer to use the "correct" destination zone either for a better readability or because not all of them are aware of the specific global nature of the MIP. So, you can configure a trust-to-untrust policy with the MIP as the destination object. This will work.
08-07-2012 05:42 AM
Hello, just to make sure we're on the same page...
PC1-------[bgroup0]FW======VPN======== Server (application and DNS)
Server 188.8.131.52 (www.test.com)
Currently, the setup is that PC1 resolves an IP address to server, www.test.com, via DNS.
Then PC1 sends a TCP SYN packet to server with src-IP 184.108.40.206 and dst-IP 220.127.116.11, and this traffic is sent over the VPN tunnel.
What you want to do is rather than being sent over the VPN tunnel, to send the traffic from PC1 to Server over the internet, out Eth3. Is this correct?
If yes, then the packet with src-ip 18.104.22.168 and dst-ip 22.214.171.124 (from PC1 to Server) will need to be translated to public IPaddresses.
I believe this can be achieved in couple different ways.
1) using src and dst nat
set policy from trust to untrust 126.96.36.199/32 188.8.131.52/32 any nat src dst ip 184.108.40.206 permit
set route 220.127.116.11/32 int ethernet3 ## to associate this IP with untrust zone
Of course the router/firewall at the server location will have to do NAT as well -- as well as making sure the server's reply is coming over the internet as well.
2) MIP with src NAT.
set int bgroup0 mip 18.104.22.168 host 22.214.171.124
set policy from trust to untrust 126.96.36.199/32 mip(188.8.131.52) any nat src permit
set route 184.108.40.206/32 int ethernet3
Goal for both options above is to translate packet from private IP 220.127.116.11->18.104.22.168 to Public IP 10.1.1.1->22.214.171.124
I don't have access to firewall at this moment to test this, but I don't see why it shouldn't work.
08-07-2012 03:36 PM
Yes that's exactly the situation Sam and I think that option 2 may well have nailed it. As yourself and Edouard said, I may have havd the policy settings incorrectly configured. Odd thing is though, when I run a tracert it just returns the Netscreen local ip for each entry.
Is there a way to check that it is indeed going through the adsl1/0 interface?
Again, thanks so much for your help on this guys, you've got me out of a sticky situation!!
08-08-2012 04:58 AM
At this point, we'll need debugs and configs...
unset ff (repeat until 'invalid id')
set ff src-ip 126.96.36.199 dst-ip 188.8.131.52
debug flow basic
*** initiate traffic ***
get db stream
In addition, you can enable logging on the policy, and "get log traffic src-ip x.x.x.x" and see if the IP is translated correctly, but debug is preferable (and definitive).