ASL 4.02 and Sentinel problems

I've been able to get Sentinel 1.4 to successfully connect to ASL 4.002, so I can try to throw out some suggestions.  I did install ASL v4, and did not try to upgrade, nor am I using an HA setup, so I may not be of much use.

Are you using the Auto Packet Filter feature?  You could try looking at the Packet Filter Violation log and see if anything is being dropped from the VPN client source addresses.  I have a friend that set up his Roadwarrior VPN with Sentinel 1.4 and preshared secret keys, and he could not get the Auto Packet Filter feature to work.  He had to manually add the packet filter rules.

It could also be some sort of IP addressing issue?  Are you assigning virtual IP addresses to the VPN users?

Are you seeing a tunnel listed in the "Security Assocations" tab of the "stats" section of the Sentinel client?  Also, do you see any routes in the "VPN Routes" section on the IPSec VPN -> Connections page?

Just trying to get more info.   

Do you use preshared keys ou certificates for your vpn connection ?

Auto packet filter, auto defined objects IPSEC:xxx, and multiple VPN roadwarrior connections work only if you use certificates.

Use NAT-T in your connection and virtual IP (unused and OUT of your  internal network, it's important) for the remote key.

If you use PSK, you must define your virtual IP in "defintions > networks", grant access to webadmin and ssh to your your virtual ip in "system > settings" and add specific rules to packet filter to access to your internal network.

Use the same virtual IP in SSH sentinel and verify your phase 2 parameters.

It must work fine (I'm using the same configuration with only one interface on the astaro box, but i had the same problem in the near past).   

Do you use preshared keys ou certificates for your vpn connection ?

Auto packet filter, auto defined objects IPSEC:xxx, and multiple VPN roadwarrior connections work only if you use certificates.

Use NAT-T in your connection and virtual IP (unused and OUT of your  internal network, it's important) for the remote key.

If you use PSK, you must define your virtual IP in "defintions > networks", grant access to webadmin and ssh to your your virtual ip in "system > settings" and add specific rules to packet filter to access to your internal network.

Use the same virtual IP in SSH sentinel and verify your phase 2 parameters.

It must work fine (I'm using the same configuration with only one interface on the astaro box, but i had the same problem in the near past).   

Jamailly,
    I am using X509 certificates. I tried to use virtual ip and I did all steps as you told, but still not working.. Yesterday I did install a new Win2k box, did setup SSH Sentinel again and I got the same problem. Connection OK, but no packets.

Best Regards
Amorim [:S]  

In fact, it seems that auto packet filter doent' work fine even with certiifcates.

As for PSK, you will have to defined your virtual IP in "Definitions > Networks" and to add specific rules with  this object (virtual ip to internal network : allow) in packet filter;

And don't forget to allow webadmin and ssh to your virtual ip in "System > settings".

Are you sure that your virtual ip is OUT of your internal network ?
For example, if your internal network is 192.168.1.0/24, you can use 192.168.2.100 as virtual ip, not 192.168.1.100.

On sentinel verifiy the virtual ip settings : you must use the same as defined in astaro box, and the mask in sentinel must be 255.255.255.0.
I encounter the same kind of problem as you  when using a mask of 255.255.255.255 in sentinel...


   

What is the network environment for the client?  Are you behing a DSL router, or a firewall?  Please provide any other information that you may think is relevent about how the client is set up.  

Moby,
   I am using a ISP by modem to make tests, no firewalls and no NAT.

Thanks
Fabio Amorim 

IIRC, all negotiation of the IPSec tunnel happens over UDP 500, meaning that no traffic passes over the ESP tunnel except data packets that are being tunneled to the remote network.  I'm wondering if your dial-up ISP drops ESP (IP protocol 50) traffic.  I've heard of some ISPs who don't feel that you should be able to establish VPNs and perform work funtions without paying for a corporate rate for internet access (AOL is one, last I heard).  

If that was the case, it would make sense that you could negotiate the tunnel (and see an active tunnel on both the client and firewall), yet no traffic passes over the tunnel since your ISP may be dropping it. 

Have you tried using NAT-T for this connection?  Try enabling the feature on both the firewall and the VPN tunnel setup in Sentinel.  When NAT-T is used all tunneled traffic traverses the Internet over UDP500, just like the IKE traffic, so if you are able to negotiate a tunnel, you should be able to pass the tunneled packets.

I don't know if that will solve your problem, but its worth a try.  I also thought the anti-VPN ISPs blocked UDP 500, but maybe this particular ISP just drops ESP packets.