Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 1456 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with virtual ip's netmask

Sam_Sorrow
I'm currently using ASL 4.017 and SSH Sentinel 1.4.1 (build 98) in a host-to-net-scenario, following the description in X509_Host_to_Net.pdf. 
Because my Client is NATèd by a DSl-Router i enabled NAT-T on both Sentinel and ASL. IPsec-Passthrough on my DSL-router is disabled.
Here my configuration in detail: 
Sentinel client--- DSL-Router (doing NAT) --- ASL --- internal network
Client-IP: 192.168.10.101
DSL-Router external IP: 217.x.x.x
ASL-external IP: 217.y.y.y
internal network: 192.168.1.0

I assigned on the ASL a virtual IP for my connection: 192.168.2.12
and on the client-side in Sentinel a enabled "Aquire virtual Ip-address" and entered manually the same IP as above and as netmask 255.255.255.0.

When i try to connect my livelog prints (after correctly detecting NAT and mapping from UDP 500 to 4500):

* cannot respond to IPsec SA request because no connection is known for 0.0.0.0/0===217.y.y.y:4500                          [@217.y.y.y]...217.x.x.x:4500                                            [user@nospam.com]===192.168.2.12/32  

I never assigned a netmask of /32 for the virtual IP!
On the ASL i found no possibility at all to define a netmask for a virtual IP and in Sentinel i defined /24. Is it a bug?
Do i have to edit ipsec.conf manually to correct the wrong netmask? Or is there a different reason for the failing vpn-connection?
Thanks in advance,
Sam     


This thread was automatically locked due to age.
Parents
  • 0
    Sam,
    i am having the same problem using super_freeswan client on my gentoo box.  I found that setting netmask to /32 (or 255.255.255.255) in your client  will make astaro recognize the connection.  You do not need to change the netmask in astaro, it sets it for you when you use virtual IP.

    Try this and tell me what happens.  You see, I get a connection established, but my routes are not set for the netmask /24 only for /32 so going to any network on the Internal_LAN, behind astaro doesn't work even though I am successfully connected.  Manually setting the route for me doesn't do anything at all.   I would really appreciate help from someone on this.

    -roman 
Reply
  • 0
    Sam,
    i am having the same problem using super_freeswan client on my gentoo box.  I found that setting netmask to /32 (or 255.255.255.255) in your client  will make astaro recognize the connection.  You do not need to change the netmask in astaro, it sets it for you when you use virtual IP.

    Try this and tell me what happens.  You see, I get a connection established, but my routes are not set for the netmask /24 only for /32 so going to any network on the Internal_LAN, behind astaro doesn't work even though I am successfully connected.  Manually setting the route for me doesn't do anything at all.   I would really appreciate help from someone on this.

    -roman 
Children
  • 0 in reply to Roman meytin
    I'm having the same problem with the routing and access to the internal networks from the VPN client.  No one seems to have an answer to this problem that I have seen.  
  • 0 in reply to C0NTR0L
    might be possible that you have selected the internal network as local network on Astaro but specified any (0.0.0.0/0) on the client side. Please ensure that you have same networks on both side. Local network on Astaro must be remote network on the client. 

    From the security perspective it is a very good idea  to set 'any' as remote network on the client side. This meassure ensures that all traffic has to pass the firewall when the tunnel is up. All traffic can filtered at the firewall - same effect could be reached by enabling 'deny split tunneling' in the Sentinel configuration.

    Greetings
    cyclops    
Cookie Information Banner