Bug 126646

Please attach your config files.

Created attachment 101524 [details]
ipsec config file

Main lan end of vpn

Attempting this configuration

   Branch LAN
 192.168.3.0/24
       |
  192.168.3.20 
       |
  _____|_____
 |    eth0   |
 |           |
 |   Branch  |
 |           |
 |    ppp0   |
 |___________|
       |
 138.130.229.129
       |
       |
    Internet
       |
       |
  203.51.193.92
       |
  _____|_____
 |    ppp0   |
 |           |
 | Corporate |
 |           |
 |    eth0   |
 |___________|
       |
 203.30.176.2
       |
 Corporate LAN
203.30.176.0/24

Created attachment 101525 [details]
ipsec config file - branch end

We have manually generated the encryption keys using the tool
provided. However the script that starts the ipsec connection seems
broken. We set -x on the script and the following is the tail of the
output.

+ '[' -n 192.168.3.0/24 -o -n 203.30.176.0/24 ']'
+ MODE=tunnel
+ '[' -n '' ']'
+ '[' -z manual ']'
+ '[' -z '' ']'
++ ip -o route get to 138.130.229.129
++ sed 's|.*src \([^ ]*\).*|\1|'
+ SRC=203.51.193.92
+ '[' manual = manual ']'
+ '[' -z '' ']'
+ AH_PROTO=hmac-sha1
+ '[' -z '' ']'
+ ESP_PROTO=3des-cbc
+ '[' tunnel = host ']'
+ '[' -z 192.168.3.0/24 ']'
+ '[' -z 203.30.176.0/24 ']'
+ ip route add to 203.30.176.0/24 via 138.130.229.129
RTNETLINK answers: Network is unreachable
+ /sbin/setkey -c
+ '[' manual = automatic ']'

What we can't get past is that the ip route command comes before the
setkey command. I messed with the script to get it to echo to stdout
the setkey command.

We tried this command manually with no luck also. We have also tried
the script at http://www.ipsec-howto.org/ with no luck (were losers).
So we are fairly stuck at this point.

I think the config is wrong... what happens if you switch the DST in
the two files? 

we have a dynamic ip addresses (we have applied for a static ip) at
the moment, so our ppp0 ip addressess are going to change from time to
time. Given that after changing the DST addressess this is the out put
of my echoie ifup.

[root@mail root]# ifup /etc/sysconfig/network-scripts/ifcfg-Dump 
Were here
RTNETLINK answers: File exists
add 138.130.228.48 138.130.228.48 esp -m tunnel -E 3des-cbc
"75de8308eb3420019b64928738bc971d";
add 138.130.228.48 138.130.228.48 esp -m tunnel -E 3des-cbc
"75de8308eb3420019b64928738bc971d";
add 138.130.228.48 138.130.228.48 ah -m tunnel -A hmac-sha1
"5b7c2e823cdc57841add1068b65399e0";
add 138.130.228.48 138.130.228.48 ah -m tunnel -A hmac-sha1
"5b7c2e823cdc57841add1068b65399e0";
spdadd 203.30.176.0/24 192.168.3.0/24 any -P out ipsec
esp/tunnel/138.130.228.48-138.130.228.48/require
ah/tunnel/138.130.228.48-138.130.228.48/require
spdadd 192.168.3.0/24 203.30.176.0/24 any -P in ipsec
esp/tunnel/138.130.228.48-138.130.228.48/require
ah/tunnel/138.130.228.48-138.130.228.48/require
[root@mail root]#  /sbin/setkey -D
No SAD entries.

Heh, you've got debugging in the script. Is setkey throwing an error?
(Don't redirect the output, etc...)

We've added debugging to the script so we can see the commands its
issuing to setkey.

Without the echoyness it only returns:

RTNETLINK answers: File exists



setkey does not appear to be throwing an error

my bad - found the redirects you were talking about

setkey is throwing parse errors

i changed script again to output the vars its using:

[root@mail root]# ifup /etc/sysconfig/network-scripts/ifcfg-Dump 
RTNETLINK answers: File exists
SRC=138.130.228.48
DST=138.130.228.48
SPI_AH_OUT=
SPI_AH_IN=
SRCNET=203.30.176.0/24
DSTNET=192.168.3.0/24
SPI_ESP_OUT=
SPI_ESP_IN=
line 1: parse error at [;]
parse failed, line 1.


thinking its got something to do with the vars
SPI_AH_IN/OUT and SPI_ESP_IN/OUT not being populated

If you're using completely manual keys, you need SPIs set.

They're arbitrary-but-unique-per-host numbers (from 1 to 65536); _IN
on one side needs to match _OUT on the other. They're connection
identifiers.

Set SPI's and got past that error ...

The key generated by network tool is the wrong length for the
default encryption types.

Manually adjusting the keys got it to work - thanks.

So, it all works now with the configuration?

The comments at the top of the ifup-ipsec script make sense now that
its working. Basically, i was missing the SPI ids and keys weren't
right for the encryption.

It doesn't seem to add the route but I *can* ping something over there :)

Closing as worksforme, then.

As we used the ipsec wizard in the system-config-network gui app,
it may be a bug that these ids and keys were incorrect or missing.

fixed in the development tree with system-config-network-1.3.17-2
I think of releasing a bugfix erratum for FC2.
Could you please test system-config-network-1.3.17-2 ??

hmm, bug #127114 seems to be a duplicate of this one..

The ipsec wizard in system-config-network-1.3.17-2 works nicely, thanks.

*** Bug 127114 has been marked as a duplicate of this bug. ***