News: This forum is now permanently frozen.
Pages: [1]
Topic: two parallel IPsec tunnels  (Read 1667 times)
« on: February 07, 2014, 17:50:15 »
DLichti *
Posts: 5

Hi,
I am trying to connect two m0n0walls (v1.8.1) via an IPsec tunnel. Since one of them connects to two different subnets, I set up two identical tunnels except for the remote subnet. Both of them work fine individually, but as soon as I enable the other one, they will both stop working and in the log, I find something like
Code:
Feb 7 17:32:10 racoon: ERROR: no configuration found for [remote gateway IP address].
Feb 7 17:32:10 racoon: ERROR: failed to begin ipsec sa negotication.

I can actually have more than one tunnel up and running, but only, if their remote gateway is different.
Even if only one of the parallel tunnels can actually be established (because I disabled it at the other endpoint), I still get the same problem.

I succesfully used a very similar configuration between two m0n0walls of version 1.3.x, but something seems to be broken with 1.8.1.

Has anyone had similar problems or knows a solution for it?

This is an excerpt from the configuration backup of one of the m0n0walls
Code:
<tunnel>
<dpddelay/>
<interface>wan</interface>
<local-subnet>
<network>lan</network>
</local-subnet>
<remote-subnet>192.168.179.0/24</remote-subnet>
<remote-gateway>[remote gateway]</remote-gateway>
<p1>
<mode>aggressive</mode>
<myident>
<fqdn>[domain name]</fqdn>
</myident>
<encryption-algorithm>blowfish</encryption-algorithm>
<hash-algorithm>sha1</hash-algorithm>
<dhgroup>2</dhgroup>
<lifetime/>
<pre-shared-key>[pre-shared key]</pre-shared-key>
<private-key/>
<cert/>
<peercert/>
<authentication_method>pre_shared_key</authentication_method>
</p1>
<p2>
<protocol>esp</protocol>
<encryption-algorithm-option>blowfish</encryption-algorithm-option>
<hash-algorithm-option>hmac_sha1</hash-algorithm-option>
<pfsgroup>2</pfsgroup>
<lifetime>3600</lifetime>
</p2>
<descr>[description]</descr>
</tunnel>
<tunnel>
<disabled/>
<dpddelay/>
<interface>wan</interface>
<local-subnet>
<network>lan</network>
</local-subnet>
<remote-subnet>192.168.180.0/24</remote-subnet>
<remote-gateway>[remote gateway]</remote-gateway>
<p1>
<mode>aggressive</mode>
<myident>
<fqdn>[domain name]</fqdn>
</myident>
<encryption-algorithm>blowfish</encryption-algorithm>
<hash-algorithm>sha1</hash-algorithm>
<dhgroup>2</dhgroup>
<lifetime/>
<pre-shared-key>[pre-shared key]</pre-shared-key>
<private-key/>
<cert/>
<peercert/>
<authentication_method>pre_shared_key</authentication_method>
</p1>
<p2>
<protocol>esp</protocol>
<encryption-algorithm-option>blowfish</encryption-algorithm-option>
<hash-algorithm-option>hmac_sha1</hash-algorithm-option>
<pfsgroup>2</pfsgroup>
<lifetime>3600</lifetime>
</p2>
<descr>[description]</descr>
</tunnel>

David
« Last Edit: February 07, 2014, 19:14:28 by DLichti »
« Reply #1 on: February 07, 2014, 18:20:20 »
Lee Sharp *****
Posts: 517

The part I need to see to understand what you are doing is the part you obfuscated.  I suspect that what you are trying to do can be done better with summery routes.  For example, of router A has subnet 192.168.20.0/24 and 192.168.21.0/24 you can make the "Local Subnet" 192.168.20.0/23 and cover both.
« Reply #2 on: February 07, 2014, 19:12:07 »
DLichti *
Posts: 5

I guess, the internal network addresses are no sensitive data, so I added them back in.

Here is my networks situation:
Site A:
m0n0wall 1.8.1 (was 1.3.4)
10.0.0.0/16

Site B:
m0n0wall 1.8.1
192.168.176.0/24
192.168.177.0/24

Site C:
m0n0wall 1.3.3
192.168.179.0/24
192.168.180.0/24
192.168.181.0/24 (not so important)

If I did the counting right, to summarize the networks at site C, I would need a tunnel to 192.168.176.0/21, but this would also comprise the networks at site B.

As I said before, I had a solution that worked fine for more than a year now between site A and site C using two parallel tunnels. Now, I can have at most one tunnel at a time from site A to each of the sites B and C. If I enable two tunnels A<->B, they will both stop working while the single one A<->C is still fine.

Of course, I could go back to version 1.3.4, but that's not the nicest solution.

David
« Last Edit: February 07, 2014, 19:28:23 by DLichti »
« Reply #3 on: February 08, 2014, 18:34:50 »
Lee Sharp *****
Posts: 517

Yep.  Site B summarizes nicely at 192.168.176.0/23 but Site C is split across two /22s, or an overlapping /21 so it will not work unless you can move 192.168.179.0 to 192.168.182.0...

So, to start, summarize site B, and it is solved.  Site c will still need parallel tunnels, but it is only connecting to site A, correct?  And Site C can not move 179 to 182, or 180 to 178, correct?

Also, you can have a tunnel between 1.8.1 and 1.34 with no issue, so leaving one as 1.34 for a while may help...  The question is, which one... Smiley
« Reply #4 on: February 08, 2014, 18:43:34 »
DLichti *
Posts: 5

I can indeed have tunnels between 1.8.1 and 1.3.4, but still limited to one between each pair of endpoints. Since moving the ranges at C is not an option for me and the connections with this site are indispensable, I will move back to 1.3.4 and hope, that this issue will be addressed in a later version.

Thank you for your help.

By the way, since this seems to be a bug, should this topic be moved to the bugs subforum?

David
« Last Edit: February 09, 2014, 15:25:30 by DLichti »
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines