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
    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   
Reply
  • 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   
Children
  • 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