Screen OS

Hi,

 

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..

Hi,

 

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.

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.

 

Regards,

Sam

Hi guys,

 

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?

 

Cheers

Hi,

 

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.

So you want to intercept traffic to a server with, say, IP 10.1.1.2, and change the dst-ip to a public IP, and route out the internet? If you know the specific ip addresses, then either policy based routing (pbr) or destination-nat+source nat should work. Sam

Hi,

 

Sam wants that certain urls are resolved to the public IPs rather than to the private ones.

Hi Sam,

 

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?

Hi,

 

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.

Hi Edouard,

 

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?

 

Cheers

Hi,

 

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.

Hello, just to make sure we're on the same page...

 

PC1-------[bgroup0]FW======VPN======== Server (application and DNS)

                  [Eth3]                  |

                    |                     |

                  Internet             Internet

                  10.1.1.1             3.3.3.3

 

PC1:  1.1.1.1

Server 2.2.2.2 (www.test.com)

bgroup0:  1.1.1.254

Eth3:  10.1.1.1

 

 

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 1.1.1.1 and dst-IP 2.2.2.2, 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 1.1.1.1 and dst-ip 2.2.2.2 (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 1.1.1.1/32 2.2.2.2/32 any nat src dst ip 3.3.3.3 permit

   set route 2.2.2.2/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 2.2.2.2 host 3.3.3.3

   set policy from trust to untrust 1.1.1.1/32 mip(2.2.2.2) any nat src permit

   set route 2.2.2.2/32 int ethernet3

 

 

 

Goal for both options above is to translate packet from private IP 1.1.1.1->2.2.2.2   to Public IP 10.1.1.1->3.3.3.3

 

 

I don't have access to firewall at this moment to test this, but I don't see why it shouldn't work.

 

 

Regards,

Sam

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!!

Hi.

 

At this point, we'll need debugs and configs...

 

 

debug:

=====

unset ff (repeat until 'invalid id')

undebug all

set ff src-ip 1.1.1.1 dst-ip 2.2.2.2

clear db

debug flow basic

 

*** initiate traffic ***

 

undebug all

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).

 

 

Regards,

Sam