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!

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
  • Hey, 

    is there anyone from Astaro to state an opinion?

    Thanks.  
  • 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 Children
No Data