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

Packets going out unencrypted!

ThomasK
Hi,

I think I found out a Problem with the VPN biult in Astaro:
Here's the setup:
 Side A=========Astaro A........ Astaro B=======Side B 
172.32.32.0/24===x.x.x.x....(e.g.router).....y.y.y.y===172.16.16.0/24
net-net-VPN works fine.

As you know there have to be two Packet-Filter-Policies on each side to allow the subnets communicating each other through the tunnel:
From Net-A to Net-B Service ANY ALLOW
From Net-B to Net-A Service ANY ALLOW

but what does hapen when the connection between Astaro A and Astaro B is lost (e.g. herdware failure on Astaro B) - O.K. the Astaro A sets the ipsec eroute to %hold. But if Astaro A reboots and the VPN-connection still can not be established, there are still the two policies allowing communication for Subnet A to Subnet B. 
The communication is allowed and because of that the packets go out UNENCRYPTED. That does not really matter in the case of tcp, but for example snmp-traps (udp)  would go out to my Provider. - O.K. you're right, the private adresses are not routed - but what if my Subnet A and Subnet B are routeable Adresses?

So correct me if I set up sth. wrong. 
a workaround could be to set up routes from net-A to net-B  to nowhere with a high metric, so that in case no ipsec eroute entry is established this high metric entry matches and my private packets won't go out to my provider.

P.S.: on other Firewalls the rules 
From Net-A to Net-B Service ANY TUNNEL
From Net-B to Net-A Service ANY TUNNEL
can be bound to the tunnel, so they won't go out when a tunnel is not established     


This thread was automatically locked due to age.
  • 0
    That's a tricky oversight! I think Astaro has to address that one...

    I guess a temporary workaround would be to add a forced route to routes.local; but you shouldn't have to do that...
      
  • 0
    Hey, 

    is there anyone from Astaro to state an opinion?

    Thanks.  
  • 0 in reply to ThomasK
    Have you tried using rules that show a "IPSec:xxxx" as the networks?  Those  should appear when the VPN is up.  If you use them instead of the static Network Definition I think you should be o.k.  If I understand how that works it means the IPSec:xxxx nets only show when the tunnel is up.  

    FreeSwan is capable of doing what you ask.  I'm assuming that ASL is leveraging that ability.  The IPSEC:xxxx nets go away if the tunnel is down and should then remove the rules from the table on the fly and put them back in when up.
      
  • 0 in reply to pablito
    Hey pablito,

    thanks for your reply, but the only "IPSec: xxx" alias/definition I can choose is "IPSec: Preshared-key" which is my preshared key (as the name says...) for this VPN-connection. No other networks are appearing in the drop down lists in the packet filter rules after the VPN-connection is up and running.
     
    I've even tried using "IPSec: Preshared-key" as network in a policy, but as u can imagine this does not add any rules to iptables.

    I still don't know if I set up sth. wrong or if this issue is really a bug in ASL 4.0xx     
  • 0
    If there is not Tunnel the packets will go to the default GW unencrypted. Sometimes this is volitional. If not you could do the following:

    Since V4.015 VPN-routes have a higher priority than normal static routes. So you could make a static route for the packets that normally should go through the tunnel. Make a route that does not have a valid destination. A route that will DROP all the packets. So if you do not have a tunnel, all the packets will be dropped. If you have a tunnel you will have a VPN-route with a higher priority that the static route and all the packets will be routed through the tunnel.

    Something additional: Please use a name in this UBB.

    Xeno   
  • 0 in reply to Xeno
    Hey Xeno,

    thank you very much for your reply! That was the solution I searched for!

    Thomas
       
  • 0 in reply to ThomasK
    To repeat what others have said, with the VPN down packets destined for the unroutable subnet will try to go out and not get too far. Noise.

    I'm all for a cleaner internet and not polluting the ISPs network with unroutable traffic.  The rest of the junk is another topic....

    Perhaps the safest thing is to create your Allow rule for VPN nets using the dynamic IPSEC::xxx nets in the right place and then right after a Deny rule for the same nets or all unroutable nets using the static definitions.  VPN up and it works, VPN down and they can't get past ASL.  Unroutables can make it into the ISP network causing additional noise.
       
  • 0 in reply to pablito
    > IPSEC::xxx

    Isn't that for roadwarriours only? (->Onlinehelp).
    For me it is working with roadwarriours only.

    2x4x  
Cookie Information Banner