03-28-2012 02:12 PM - edited 03-28-2012 03:36 PM
I received a SSG5 router to play around with and get my feet wet in the world of routing. I configured a dialup VPN and I can get the client to connect and get an IP address, but I cannot ping the default gateway. Also, the VPN session only stays up for about 3 minutes then the security association expires. Not sure about that one either. Any help is greatly appreciated.
03-28-2012 07:40 PM
I'm assuming that by "default gateway" you mean the xx.xx.xx.1 address listed as gateway for eth0/0.
So, you have the gateway address of xx.xx.xx.1 in the Untrust zone, and the VPN client in the Untrust zone as well, but your dial-up VPN policy is for traffic between zone Untrust and Trust, hence there's no policy to facilitate traffic between the VPN client and the default gateway.
The SA would normally expire if there's no traffic (e.g. real traffic, or keep-alives, or something else). Depending on the client, it can be "dialed up" again when there's a need. To see if there's a problem, try, for example, pinging continuously an IP in your Trust zone from the VPN client, and see if the SA will get destroyed while doing that.
03-29-2012 03:03 PM
No, I'm still unable to ping 18.104.22.168 or any IP in the trust zone. I did notice this notification pop up on the SSG5 monitor: VPN monitoring for VPN <vpnclient_tunnel> has deactivated the SA with ID 0x00008C. Could this have something to do with the VPN dropping the client after a couple of minutes?
03-29-2012 03:17 PM
What is the VPN client you're using? Could you please post the IP address of the client (not the VPN-assigned one) and a trace-route between the client and 22.214.171.124 before and after VPN is established.
03-29-2012 04:48 PM
I'm using Shrewsoft as the client. If there's a better one out there, let me know. As far as the traceroutes go, there isn't much to say. Before the VPN connection, it gets out to the internet and dies and when the VPN is connected, it doesn't go anywhere.
03-29-2012 06:08 PM
Also, you can enable logging on your VPN policies and see if the traffic gets logged there.
Then, try pinging something on the inside of the firewall (172.168.1.x).
Finally, we may need to run a debug session on the firewall to see what really is happening there.
03-30-2012 12:06 AM
Have you correctly configured what is named Topology in the SchrewSoft VPN client? This is step 9 in the KB22074.
VPN monitoring with default settings will not work with SchrewSoft client. It will permanently drop and re-negotiate the SAs. You should select Trust interface as the source one for VPN monitoring. The Trust interface IP should belong to the topology (VPN Proxy ID) for this to work.
03-30-2012 01:30 PM
Thanks for the information Edouard, but if I follow step 9 in that bulletin, I don't get any security associations to establish. If I require a Policy Generation, I'll get one to establish, but only for a couple of minutes. I'll rebuild my VPN client to match the bulletin posted and retry. Nikolay, I've got the logging turned on for the policies I have configured. How do I check the logs and see what's going on with those? Thanks for sticking with me on this. I'm learning a lot.
03-31-2012 07:20 AM
The Web UI of the firewall has a great visual display. Login to the firewall with a web browser, navigate to Policies, find your policy and click on the little table-like icon. That will give you the log for that policy. You may want to also enable logging at the beginning of the session.
04-01-2012 12:44 AM
From the trace-route, it looks that the VPN client is unable to push traffic through the tunnel.
Try looking at the configuration of client, if possible, provide screenshot of client configuration.
Also, for initial analysis, you can disable monitoring (to keep things simple)
04-02-2012 12:27 AM
The Proxy IDs are automatically derived from the VPN-policy if policy-based VPN is used. If the incoming VPN policy contains a single address object in its destination field, e.g. 192.168.1.0/24, and multiple protocols or "Any" the following Proxy ID will be used on the FW: Local IP 192.168.1.0/24 Remote IP 255.255.255.255/32 Protocol Any. If the destination field contains multiple address objects or a group of objects the Local IP will be 0.0.0.0/0. If you need an access to multiple LANs you should configure multiple VPN policies, one policy for each pair of Local IP-Remote IP. In this case I would recommend to use ScreenOS 6.3 and route-based VPN.
The Proxy ID (IDs) configured on the client should match those on the Firewall.
04-10-2012 05:16 PM
Thanks for all the comments, but it looks like I'm moving backwards in my configuration. Is Policy based routing the way to go? I guess at this point, I just want the tunnel to come up and be able to move around on the trust network. I'm willing to try a different approach if need be. A simple setup will work. I can always add more security as I learn more about the device and policies. I'm really just frustrated right now and will try anything to move forward again. Thanks again.
04-10-2012 05:23 PM
I followed the instructions in KB22074 for the Shrew Soft VPN client. Now, I can't even bring the tunnel up. Before, I was able to bring the tunnel up, but the security assocations never established. Here is a snapshot of the event log. If anyone has ideas, let me know. I'll be happy to share any configs or snapshots you think might help out.
04-11-2012 02:29 AM
You should create an IP pool. An IP from this pool will be assigned to the client during the extended authentication (XAUTH). The pool can be mapped to the default XAUTH settings (VPNs -> AutoKeys Advanced -> XAuth settings), to the Gateway Configuration or to the user profile. The settings in the user profile override those in the GW configuration and the last override the default settings. The same rule holds true for the DNS and WINS server IPs which can be assigned the same way.
You can also assign static IPs to each user in the user profile. This is usually used if the access policies are very restrictive and each user should have has a specific set of access rights.
04-19-2012 08:09 PM
I've tried various ways of configuring this router. I even started from scratch and rebuilt the whole thing. I'm convinced I have some sort of problem with my policies and the configuration of the client. How does DNS figure into this? I haven't added anything as far as DNS entries into the VPN, just the DNS on the untrust interface (ethernet 0/0). I still can't get a security association to come up using the knowledge base you suggested in previous posts with the Shrewsoft client. That's my first problem and the one I need to concentrate on. My knowledge of subnetting has hampered this process as I am just starting out, so here's what I can tell you. The trust zone is set for 126.96.36.199/24. The VPN IP pool starts at 188.8.131.52. I know that the VPN needs to be on a different subnet than the trust zone or internal LAN. Can you please give me an idea of how the policies need to be set up? I don't need any special permissions or anything. I just need the VPN connection to be able to access the 184.108.40.206/24.
Thanks again for your help,