Howto force all traffic through vpn-tunnel

You don't want 'Any' in there.  This needs to just have the local networks.  You need to create a policy route for the traffic you want to force through the tunnel.

Thanks Bob,

I also thaught so, but couldn't get it to work right.
I made a policy route:

Route Type: Gateway route
Source Interface: Internal
Source Network: Internal (Network)
Service: POP3
Destination Network: Any
Gateway: Internal IP of HQ ASG

When I try to fetch mail via POP, I can see in the Packet Filter Log, that the request for Port 110 are still to the IP of the provider and are dropped.

What is wrong?

Walter, Thank you for starting this discussion.  I have thought of offering to do the same thing for a client, but, apparently, I would have wasted a lot of time "fighting" with policy routes.

Have you tried turning on strict routing on both sides and replacing 'Any' with 'Internal (Network main office)' in the very first connection above (the one for the main office)?  Other than that, it all looks like what I understand after Gert's comments above.

Gert, I had hoped to be able to send selected traffic through the VPN tunnel.  This approach sends ALL non-internal traffic through the tunnel.  Do I understand you correctly that VPN routes are not subject to entries in 'Network >> Routing'?

Cheers - Bob

Bob,

i'm still fighting.

As discribed above, when I replace 'Any' with 'Internal (Network main office)', I have a stable connection.
I have not yet used strict routing.

Following I show you the log of one cycle at the branch office:

2009:02:07-12:31:54 (none) ipsec_starter[10030]: Starting strongSwan 4.2.3 IPsec [starter]...
2009:02:07-12:31:54 (none) ipsec_starter[10039]: IP address or index of physical interface changed -> reinit of ipsec interface
2009:02:07-12:31:55 (none) pluto[10042]: Starting Pluto (strongSwan Version 4.2.3 THREADS LIBLDAP VENDORID CISCO_QUIRKS)
2009:02:07-12:31:55 (none) pluto[10042]: including NAT-Traversal patch (Version 0.6c) [disabled]
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_AES_CBC encryption: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_BLOWFISH_CBC encryption: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_SERPENT_CBC encryption: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_SHA2_256 hash: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_SHA2_384 hash: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_SHA2_512 hash: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_TWOFISH_CBC encryption: Ok
2009:02:07-12:31:55 (none) pluto[10042]: ike_alg: Activating OAKLEY_TWOFISH_CBC_SSH encryption: Ok
2009:02:07-12:31:55 (none) pluto[10042]: Testing registered IKE encryption algorithms:
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_DES_CBC self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_BLOWFISH_CBC self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_3DES_CBC self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_AES_CBC self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SERPENT_CBC self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_TWOFISH_CBC self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_TWOFISH_CBC_SSH self-test not available
2009:02:07-12:31:55 (none) pluto[10042]: Testing registered IKE hash algorithms:
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_MD5 hash self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_MD5 hmac self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA hash self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA hmac self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA2_256 hash self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA2_256 hmac self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA2_384 hash self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA2_384 hmac self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA2_512 hash self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: OAKLEY_SHA2_512 hmac self-test passed
2009:02:07-12:31:55 (none) pluto[10042]: All crypto self-tests passed
2009:02:07-12:31:55 (none) pluto[10042]: Using KLIPS IPsec interface code
2009:02:07-12:31:55 (none) pluto[10042]: Changing to directory '/etc/ipsec.d/cacerts'
2009:02:07-12:31:55 (none) pluto[10042]: loaded CA cert file 'VPN Signing CA.pem' (3073 bytes)
2009:02:07-12:31:55 (none) pluto[10042]: loaded CA cert file 'HQ***-local Verification CA 1.pem' (1260 bytes)
2009:02:07-12:31:55 (none) pluto[10042]: Changing to directory '/etc/ipsec.d/aacerts'
2009:02:07-12:31:55 (none) pluto[10042]: Changing to directory '/etc/ipsec.d/ocspcerts'
2009:02:07-12:31:55 (none) pluto[10042]: Changing to directory '/etc/ipsec.d/crls'
2009:02:07-12:31:55 (none) pluto[10042]: listening for IKE messages
2009:02:07-12:31:55 (none) pluto[10042]: adding interface ipsec0/ppp0 91.10.132.***:500
2009:02:07-12:31:55 (none) pluto[10042]: loading secrets from "/etc/ipsec.secrets"
2009:02:07-12:31:55 (none) pluto[10042]: loaded private key file '/etc/ipsec.d/private/BO***-local.pem' (891 bytes)
2009:02:07-12:31:55 (none) pluto[10042]: loaded host cert file '/etc/ipsec.d/hostcerts/x509cert.pem' (3811 bytes)
2009:02:07-12:31:55 (none) pluto[10042]: loaded host cert file '/etc/ipsec.d/hostcerts/REF_qhbIlpZXnd_70018a5a.pem' (1613 bytes)
2009:02:07-12:31:55 (none) pluto[10042]: added connection description "S_vpn_0"
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: initiating Main Mode
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: ignoring Vendor ID payload [strongSwan 4.2.3]
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: ignoring Vendor ID payload [Cisco-Unity]
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: received Vendor ID payload [XAUTH]
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: received Vendor ID payload [Dead Peer Detection]
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: we have a cert and are sending it
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: Peer ID is ID_FQDN: '@fw.hq***.loc'
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: crl not found
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: certificate status unknown
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #1: ISAKMP SA established
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #2: Dead Peer Detection (RFC 3706) enabled
2009:02:07-12:31:55 (none) pluto[10042]: "S_vpn_0" #2: sent QI2, IPsec SA established {ESP=>0x5f45bad2 

Bob,

I knew it couldn't work, but I tried it. Switching 'any' to 'internal' only on one side get no connection.

I now switched on strict routing and wait for the next cycle.

Nope, this cycle also was around 5 Minutes.

I don't think either of these relate to your problem, but I see two things that are set on the 'Advanced' tab.  
[LIST=1]

• It looks like you don't have NAT-T enabled, but I would have expected that it would be needed; what do you think?
  
  
• "crl not found" seems odd.  If you have automatic fetching enabled, the manual comments, "If you use this feature, make sure that you set the packet filter rules accordingly, so that the CRL distribution server can be accessed."

[/LIST]
The other thing that comes to mind is hardware.  I was going to suggest that you switch the interfaces used for Internal and External to rule out cables and such.  You might want to try that, but I see that your interface is PPPoE, and I recall that Barry talked about setting the MTU of the External interface, setting it to half-duplex and/or setting the speed fixed instead of auto.

I hope Gert comes back by this thread!

Cheers - Bob

Bob,

I had NAT-T enabled, but because both sides are not natted (direct connection to DSL) I disabled it.

CRL is not needed for my opinion since we use a self signed CA and all cert are under my control.

The MTU is set to default. That means 'Allow Path MTU Discovery' is enabled and MTU set to 1420. Interface MTU is 1492.

Hardware for branch office is a brandnew ASG 110 Rev. 2

Hardware in HQ is a PC, that runs since several month with 3 site-2-site-vpns without problems. But they all tunnel only to internal network.

Good, I was just trying to make sense out of something that seems to stop suddenly.  I notice that the tunnel was shut down after 256 (2^8) seconds had passed.  Is it always exactly four minutes and 17 seconds after the last "up" message?

Chees - Bob

Guys,
i am still there but traveling, i get back to you on monday.
regards 
Gert

Bob,

I just calculated some differences, but it is not the same. It is between 4 and 5 minutes.

I tried to sort out hardware problems on the HQ side and built a new vpn-tunnel to my home box. 
Surprise or not.
It's just the same. It's shutting down after 4 min and something.

Next thing. I'll grab another new ASG 110 and try the tunnel.

I run out of ideas.

I took a brandnew ASG 110. Just basic setup. No restore from a backup. Created new certs and built tunnel to my home box.

Same behavior. Only difference is, that it is shutting down after less than 4 minutes.

Where is the bug?

I run out of ideas.

I took a brandnew ASG 110. Just basic setup. No restore from a backup. Created new certs and built tunnel to my home box.

Same behavior. Only difference is, that it is shutting down after less than 4 minutes.

Where is the bug?

Now I can sort out hardware problems and problems with the DSL-line.
Because it is weekend and I'm not disturbing someone, I biult a tunnel between two remote ASGs and tried the 'Any'.
Same result as here. Around 4 min cycle.

So it only can be configuration. They are all configured by me with the same scheme as it is shown above.

I'm still fighting.

I thaught, it is a common situation and had to be solved many times before.

No ideas? No hints, where to search?

Jeeepee,

I changed the policy from AES-256 PFS to AES-128 and now the tunnel is open more than an hour.
The first rekeying occured without problems.

Can someone explain me, why the stability of the tunnel depends on the keylength?

Anyhow, I will watch the stability for another day, but the costumer is waiting for his solution.

You know, Walter, I bet you could change to any other policy.  Don't ask me why, I think it must be magic.

How about it, does anyone here know?

Cheers - Bob
PS So, you are confirming that the only thing you changed from the prior page was "AES-256 PFS' to "AES-128" - right?

Bob,

it really was only the key lenght, that is changed.

I tried many variation for configuration, but only changed one parameter at a time. I had already tried AES-256 without PFS, but that didn't help. Then I changed MTU and certs and so on.

Now it's running stable for more then 15 hours and I had to tweak some more things, to get everything working. (Notification, Up-2-Date, ACC etc.).

Perhaps I'll try some other policies out of curiosity the other day, but in the moment i'm happy, that I can keep my costumer satisfied with a working solution.
(I think AES-128 is not too unsecure to live with it).

Quick question for you now that you are routing all your traffic through the VPN for your remote site successfully.  I am assuming you lost lost your ability  to remotely admin the box through the remote office's external IP address, is that correct?

So now when you need to access the webadmin you need to use the internal addressing for the remote astaro firewall? I am assuming this is normal now that all traffic is being routed.

That's what I am seeing on my end anyways.

Thanks,
-Scott

ScottL,

thank you for pointing me to an aspect, I haven't seen before.

I established a second site-to-site-tunnel of the branch office to my home box and this is working.

As far as I see it now, for real road warrior administration, I have to go through main offices gateway. But what if this tunnel fails?

Create a DynDNS account and a host definition on your ASG.  Add this host to allowed networks for Admin and ssh.  When you need to access from somewhere else and not via the VPN, discover your public IP, change the DynDNS entry and login to the ASG.

For added security, you could leave the DynDNS account pointing to the primary External IP on your ASG; remember to reset the DynDNS entry when you finish.

Cheers - Bob

This has been working great for me for awhile now (all traffic from remote branch through site to site vpn to HQ)...but last night I applied 7.400 and 7.401 and now it appears that the VPN routing has changed (not taking precedence anymore).  The updates appeared to be applied ok and the firewall came back up, as did the VPN tunnel....but traffic is not routing through the tunnel anymore; anyone else see this?

Before the update with the vpn set up on the remote site so that HQ had 'Any'.  When this was set up I could not manage the FW from external so I had to manage it through the VPN from HQ side.  After the update of course I cannot reach the FW from the HQ side, but the external access works again.  To me it seems that the VPN routing has stopped working?

On the HQ side I have not updated yet so it is still 7.306.  I am hesitant to update it as I don't want to restore two firewalls from backup.  Any thoughts?

You might check this thread: https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/53075