12-28-2011 11:11 PM
Hope you can help. Dialup vpn can get to external vpns but site to site can't.
1) Our main office netscreen have policy based vpn to customer sites as well as firewall to our internal servers.
Internal user can get to all resouces including customer vpns.
2) Offsite user use Dialup vpn(netscreen remote) they can also connect to all resouces.
3) we now have a satellite office with route based site to site vpn back to the main office. Everthing works except they can't get to to customer vpns or any external vpns behind our main office.
I have tried both VPN based and Router based VPN both does not work
Policy based vpn I get error "traffic denied" in policy log
Route based vpn I can't find any logs.
Our internal ip range is 192.168.0.0/23
customer vpn ip range is 192.168.50.0
In my policies I cover the range using 192.168.0.0/18 and Permit Any.
Hope someone can help
12-30-2011 05:31 AM
Without a diagram and a full listing of the policies from your two sites and the customer VPN I can't be sure. But I would suspect that the issue is the policy from the customer vpn to your main site.
The customer vpn probably has a permit connection to your main site lan only.
This means your remote ip range for the satellite office would need to have a nat to a local ip on the 192.168.0.0/23 of the main office.
If my guesses are correct, for this you would.
01-02-2012 08:00 PM
Yes you are correct.
The policy on Main only allows 192.168.0.0/23 to access customer sties.
I am not familiar with DIP. Our satelite site is 184.108.40.206/23. Do I still need to use DIP since the subnets do not overlap?
PS: I do not want to change the policies on the customer sites if I can help it.
01-03-2012 04:35 PM
You will need the dip and policy in order to accomadate the customer tunnel address space. This tunnel connects to your main site and expects all addresses to be sourced from the 192.168.0.0/23 space. You will be doing a source translation from the 220.127.116.11/23 to your dip address before forwarding the traffic down the client tunnel.
The policy will take any traffic from 18.104.22.168/23 to 22.214.171.124 and do the source translation on the dip address selected from the 192.168.0.0/23 space.
02-17-2012 04:26 PM
Sorry for the late reply,
It been a hectic month but I was able to configure the following:
- DIP with ID 4 on the main with range 192.168.0.101 to 192.168.0.150. (Note this range is available and unused)
- Create a policy to allow traffic with DIP ID 4.
I can see traffic is going through the policy because the policy is logging the events and I can see "Translated Source Address" is correct 192.168.0.150/23 and is going to customer address on the 192.168.50.x.
But I still can't ping the customer address Close Reason -> Close- AGE OUT.
I don't know why but 192.168.0.x/23 is the internal trusted range and it should have worked. Access to internal network works.
Any more tips.
As a test:
I also found if I create a Policy based Dial up VPN with NAT enabled it connect to customer site without an issue but when I tried creating a Route based Dial up VPN with and without DIP as above I get the same problem Close - AGE OUT. hope this test helps.
02-21-2012 03:58 AM
From your description it seems like there must be a routing issue of some kind. But I am at a loss to see what is missing from what is here.
You can do a flow capture on the traffic that is hitting the policy but not completing. Use debug flow basic for this and then pull the stream that shows each step of the traffic process. You will set the filters to be the source and destination ip addresses that you use in the test.
DEBUG FLOW BASIC :
1. undebug all - we are assuring that the debug utility is not already running.
2. get ffilter - we would expect to get no response. This tells us we have not set up any flow filters as of yet. If you should see filters listed you can delete them with unset ffilter.
3. set ffilter src-ip x.x.x.x(computer A) dst-ip x.x.x.x(computer B)
set ffilter src-ip x.x.x.x(Computer B) dst-ip x.x.x.x(computer A) by doing this we can observe the packets flowing in each direction and where any possible problems may be. Basically we want to define the end points of communication.
5. clear db - this will clear the debugging cache.
6. debug flow basic - this turns the debugging utility on.
7. initiate the traffic you are interested in capturing.
8. get db stream - this is the actual packet capture output that we want.
Remove the configuration when done:
9. undebug all - turns the utility back off.
10.unset ffilter 0 - this will need to be done twice, once for each filter that we set up earlier.
11.clear db - this will clear the cache.
05-22-2012 06:49 PM
Thanks for you help. You have been GREAT!.
The debug return "no scr xlate choose interface bgroup5/1 as outgoing phy if no loop on ifp bgroup5/1"
I don't know why but I change the tunnel interface from untrusted to trusted and everything started to work. i am not sure why but it works.
When you have the tunnel set to untrusted the policy can see traffic but it times out. If you know what the reason might be please let me know otherwise many thanks.