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?

It sounds like you need a packet filter rule allowing the packets to pass.

Let me restate this to see if I understand.

You have a main office with an Astaro that has the POP3 Proxy enabled.  You have a remote office with another Astaro connected to the main office via Site-to-Site VPN.  You want the people in the remote office to receive their emails through the proxy in the main office to take advantage of AV and spam filtering.

Is that correct?

Cheers - Bob

Hi guys, 
i need to correct you. 

You cannot force traffic through the tunnel via policy routes, these routes are in a seperate routing table and VPN routes will have precedence. 

Properly setting up Ipsec eith Any as the remote network works, if properly setup. 

We have clients using this tunneling traffic from GUEST networks in meetings rooms encrypted to the main firewall where they route it directly to the internet. 

if you specify your ipsec setup more precisely i might be able to find the missconfiguration.

regards
Gert

Gert, Thanks for your participation. It is, after all, your brain inside the Astaro device.

It's not clear to me why the VPN routes have precedence.  How would we know that from the documentation?

Cheers - Bob

Thank you guys for your comments.

Bob, you made a very good and clear discription of what I want to achieve.

Gert, without knowing the details, my first idea was to use 'Any' for the remote network, but this doesn't work stable.

Let us find the reason.

Setup at main office:

IPSec Connection: 
Remote Gateway:  Definition of branch office gateway
Local Interface:    External (WAN)
Policy:                AES-256 PFS
Local Networks:   Any
Auto packet filter: On
Strict routing:      Off

Remote Gateways:
Gateway type:     Initiate connection
Gateway:            Dyndns-IP of branch office
Authentication type: Local X509 Certificate
Certificate:          Local Cert of branch office
VPN ID Type:       fqdn
VPN ID:               Hostname branch office
Remote Networks: Internal Network branch office

Setup at branch office:

IPSec Connection: 
Remote Gateway:  Definition of main office gateway
Local Interface:    External (WAN)
Policy:                AES-256 PFS
Local Networks:    Internal (Network)
Auto packet filter: On
Strict routing:      Off

Remote Gateways:
Gateway type:     Initiate connection
Gateway:            IP of main office
Authentication type: Local X509 Certificate
Certificate:          Local Cert of main office
VPN ID Type:       fqdn
VPN ID:               Hostname main office
Remote Networks: Any


This doesn't work stable. If I change 'Any' to 'Internal (Network main office)' it's running stable. No different certs or policies.

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

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?

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.