Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 2182 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.
Parents
  • 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.
      
Reply
  • 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.
      
Children
  • 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     
Cookie Information Banner