Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 2228 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

SSH Sentinel 1.4 / Virtual IP / VPN IPSEC

jam
I'm using SSH sentinel 1.4 to access an astaro v4.002 box.

I have defined :
- a remote key with a virtual IP belonging to my internal network, with auto packet filter to ON, 
- a roadwarrior VPN IPSEC connection using this remote key and auto packet filter to ON to access to my internal network
- allow internal network to access to webadmin and  ssh in system settings.

With this configuration I can establish the VPN tunnel, access to webadmin,  ssh and ping on my astaro box, but I'm unable to access to internal network. Nothing seems to go across the astaro box from roadwarrior. Neither ping to host in the internal network doesn't reply (ICMP filter rules are OK, cimp and ping forwards are well allowed);

What's the matter ? 
Do I forget something ?
Do I need specific rules in packet filter (normally with auto packet filter=on, it's not necessary) ?     

By advance, thanks for your help;

    


This thread was automatically locked due to age.
Parents
  • 0
    You can see if you need a packet filter rule by checking the Packet Filter Violation Logs.  You should see the traffic getting dropped if the Auto Packet Filter rules did not get created properly.

    I haven't looked into this as much as I'd like, but I was under the impression that you couldn't assign a virtual IP address out of your LAN range.  If you did, it would require the Astaro firewall to ARP when your LAN hosts try to send a packet to the virtual IP.  I wasn't aware that the firewall would do this with the WebAdmin configuration (someone please correct me if I am wrong).  Basically, your LAN machines will think your virtual IPs are on the LAN, but if the firewall does not respond to ARP requests for the virtual IPs, then the LAN hosts cannot send the packets -- they will never know what MAC address to put in the packets.

    If you choose another private network range for the virtual IPs, then all LAN hosts would have to send the packets to the firewall, because those IPs are not in your local LAN subnet and the firewall will be their default gateway.  

    I use SSH Sentinel 1.4 to connect to my home network through Astaro 4.002.  For example, if my LAN subnet was 192.168.1.0 255.255.255.0, I would choose a virtual IP in the subnet range 192.168.2.0  255.255.255.0.  This configuration is currently working for me.

    Hope that helps.   
  • 0 in reply to Moby
    I've already look in the filter livelog and didin't see anything block from my virtual ip. 

    In your example in your mail, if your internal network is 192.168.1.0/24 and that you use a virtual ip 192.168.2.0/24 you are using a virtual ip OUT from your internal network. 

    Are you sure of the network mask given in your response ?  
  • 0 in reply to jam
    In the example, my LAN network is 192.168.1.0/24.  So 192.168.1.1 is the firewall's internal interface, and the hosts are anywhere between .2 and .254.  The default gateway for these hosts is 192.168.1.1 (the firewall).

    I have two different roadwarrior IPSec VPN connections that are being assigned virtual IPs and Auto Packet Filter.  One of the virtual IPs is 192.168.2.4 and the other is 192.168.2.100.  Everything works fine for this setup, and you can access any of the internal machines (assuming your MTU is low enough.. if it is not then pings are about the only thing that will work).

    If you change the virtual IP address (on both the client and the firewall) to 192.168.1.101 (an unused LAN address), the VPN tunnel will not work.  I have never been able to get VPN tunnels to work when the virtual IP address is in the local LAN subnet.  I think that this doesn't work because the firewall won't send ARP replies for the 192.168.1.101 address.

    I wasn't sure exactly what you were asking, so I hope this answers your questions.


      
Reply
  • 0 in reply to jam
    In the example, my LAN network is 192.168.1.0/24.  So 192.168.1.1 is the firewall's internal interface, and the hosts are anywhere between .2 and .254.  The default gateway for these hosts is 192.168.1.1 (the firewall).

    I have two different roadwarrior IPSec VPN connections that are being assigned virtual IPs and Auto Packet Filter.  One of the virtual IPs is 192.168.2.4 and the other is 192.168.2.100.  Everything works fine for this setup, and you can access any of the internal machines (assuming your MTU is low enough.. if it is not then pings are about the only thing that will work).

    If you change the virtual IP address (on both the client and the firewall) to 192.168.1.101 (an unused LAN address), the VPN tunnel will not work.  I have never been able to get VPN tunnels to work when the virtual IP address is in the local LAN subnet.  I think that this doesn't work because the firewall won't send ARP replies for the 192.168.1.101 address.

    I wasn't sure exactly what you were asking, so I hope this answers your questions.


      
Children
  • 0 in reply to Moby
    I've found my problem. My VPN connection on astaro was defined with two remote keys allowed : one with a virtual ip (192.168.100.150) from my internal network (192.168.100.0/24), the other with virtual ip (192.168.150.1) out from my internal network.

    If  I keep only the one with virtual ip (192.168.150.1) out of my network it works pretty fine, except that auto packet filter to ON doesn't seem to work as expected : I have to add specific rules (roadwarrior to internal_netwrok : allow)  to packet filter to be able to access my internal network. 

    Do you have the same problem with auto packet filter ?

    NB: If I use a virtual ip from my internal network, I can establish the VPN tunnel, reach the astaro box (ping, webadmin, ssh) but nothing more (and especially unable to access internal network).

    Thanks for your help.
       
  • 0 in reply to jam
    The Auto Packet Filter is working fine for my VPN connection, but one of my friends who has set up a VPN to his house had the same problem with Auto Packet Filter not working.  We haven't had time to try and figure out the reason why it did not work, but I'll post an update if I figure something out.  
  • 0 in reply to jam
    One thing that comes to mind about Auto Packet Filter (APF) is that you can turn APF on or off in two different places.  You have the option to select APF in the "Connections" section of an IPSec tunnel, and in the "Remote Keys" section, when you are defining the remote user.  I have it turned on in both places.  

    I don't know if that is causing your problem, but it is probably worth checking.  
  • 0 in reply to Moby
    Heh, just found in the "known issues" doc why my autofilter doesn't work "ID426 o 4.000 IPsec Autofilter does not work with Preshared Keys (PSK)
    ----------------------------------------------------------------------
    Description:  When using Autofilter for connections with preshared keys,
                  the appropriate rules are not set.
    Workaround:   Use X509 keys instead
    Fix:          ---
    "

    Yeah I'm using Pre-shared keys and I'm guessing you probably are to. Should probably try upgrading to certs as that is what Moby is using and auto-filter works I guess they'll probably fix this feature fairly soon for PSK.  
  • 0 in reply to Kfalde
    I was using PSK for these VPN tunnel
    Thnaks for these explanation

    does anybody know when this feature will be working fine ?.   
  • 0 in reply to jam
    I have just made some tests, using certificates for my VPN roadwarrior tunnel.

    I use NAT-T and my virtual ip is out of my internal network.

    auto packet filter still doesn't work (it's well to on in remote key and in connection)

    Objects IPSeC:xxxx are without effects when used in packet filter rules. I have to defined my virtual iP manually (defintions>networks) and to use it in packet filter.

    Is it a bug about auto packet filter and auto defined IPSEC:xxx objects ?
      
Cookie Information Banner