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 220.127.116.11 (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 18.104.22.168 and dst-IP 22.214.171.124, 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 126.96.36.199 and dst-ip 188.8.131.52 (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 184.108.40.206/32 220.127.116.11/32 any nat src dst ip 18.104.22.168 permit
set route 22.214.171.124/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 126.96.36.199 host 188.8.131.52
set policy from trust to untrust 184.108.40.206/32 mip(220.127.116.11) any nat src permit
set route 18.104.22.168/32 int ethernet3
Goal for both options above is to translate packet from private IP 22.214.171.124->126.96.36.199 to Public IP 10.1.1.1->188.8.131.52
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 184.108.40.206 dst-ip 220.127.116.11
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).