ScreenOS Firewalls (NOT SRX)
Reply
Distinguished Expert
echidov
Posts: 858
Registered: ‎11-02-2009

Re: Redirect certain websites through untrust interface

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.

Kind regards,
Edouard
Trusted Expert
samc
Posts: 508
Registered: ‎07-23-2012

Re: Redirect certain websites through untrust interface

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

B77
Contributor
B77
Posts: 28
Registered: ‎11-21-2010
0

Re: Redirect certain websites through untrust interface

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

Trusted Expert
samc
Posts: 508
Registered: ‎07-23-2012
0

Re: Redirect certain websites through untrust interface

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

 

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.