Help! Ipsec-tools/Racoon link through NAT .. "ip route" fails

Help! Help!

I found a copy of ipsec-tools-0.4 in RPM format and was thereby able to get
software on my machine that recognizes NAT-traversal in an IPSEC link.

I added "nat_traversal on" in the configuration file and it is being
recognized.

However... something is still wrong. Now, I never see Racoon trying to
negotiate with anyone when I ping to an address that's supposed to be on
the other side of the tunnel.

Let's say:
my address = 192.168.254.111
my gateway (NAT-equipped router to cable-modem) = 192.168.254.254
remote gateway = 65.54.43.32
remote network should attach to mine at = 192.168.222.0/24

The script provided by Red Hat attempts:

ip route to 192.168.222.0/24 via 65.54.43.32

and is told "network is unreachable." Which makes a certain amount of sense
because 65.54.43.32 is indeed not on my local network; it is "outside." To
get there, the traffic must pass _through_ my gateway (192.168.254.254),
and I don't think what I'm saying to Linux right now tells it that.

What do I need to do?


Sundial Services

On 2004-11-27, Sundial Services <(E-Mail Removed)> wrote:
> Help! Help!
>
> [snipped]
>
> However... something is still wrong. Now, I never see Racoon trying to
> negotiate with anyone when I ping to an address that's supposed to be on
> the other side of the tunnel.
>
Erm....racoon.conf and your setkey commands (or at least the output from
'setkey -DP')?

You might have configured your policies to do this. Racoon does the
negotiating however its the kernel that says "time to negotiate, oi racoon!".

> What do I need to do?
>
tell us the useful bits :P

Cheers

Alex

Alexander Clouter wrote:
>> However... something is still wrong. Now, I never see Racoon trying to
>> negotiate with anyone when I ping to an address that's supposed to be on
>> the other side of the tunnel.
> Erm....racoon.conf and your setkey commands (or at least the output from
> 'setkey -DP')?
>
> You might have configured your policies to do this. Racoon does the
> negotiating however its the kernel that says "time to negotiate, oi
> racoon!".
>
>> What do I need to do?
>>
> tell us the useful bits :P


The computer in this case is strictly operating as a client... talking to a
remote hardware router. The setup is Red Hat and the commands being issued
are those issued by 'ifup-ipsec' on that system. I don't have easy access
to them /now/ to repeat them, but I do believe that they are correct,
having once dumped them out.

Setkey -DP is interesting:
[snip!]
0.0.0.0/0[any] 0.0.0.0/0[any] any
in none
created: Nov 27 18:37:19 2004 lastused:
lifetime: 0(s) validtime: 0(s)
spid=371 seq=3 pid=14862
refcnt=1
0.0.0.0/0[any] 0.0.0.0/0[any] any
in none
created: Nov 27 18:37:19 2004 lastused:
lifetime: 0(s) validtime: 0(s)
spid=355 seq=2 pid=14862
refcnt=1
0.0.0.0/0[any] 0.0.0.0/0[any] any
out none
created: Nov 27 18:37:19 2004 lastused:
lifetime: 0(s) validtime: 0(s)
spid=380 seq=1 pid=14862
refcnt=1
0.0.0.0/0[any] 0.0.0.0/0[any] any
out none
created: Nov 27 18:37:19 2004 lastused:
lifetime: 0(s) validtime: 0(s)
spid=364 seq=0 pid=14862
refcnt=1
[/snip!]

All zeroes!

The "ifup-ipsec" command gave "network is unreachable." A query of the
"route" command shows no routes whatsoever mentioning the VPN
address-range...

"ping" of the desired address says:
"Connect: invalid argument."

"ip route get to <<any VPN address>>" shows a perfectly uninteresting route,
going out the default gateway.

Sundial Services wrote:
> The "ifup-ipsec" command gave "network is unreachable." A query of the
> "route" command shows no routes whatsoever mentioning the VPN
> address-range...
>
> "ping" of the desired address says:
> "Connect: invalid argument."
>
> "ip route get to <<any VPN address>>" shows a perfectly uninteresting
> route, going out the default gateway.


Everything that my poor brain can see says that "Linux doesn't know that
these addresses are special." It doesn't have any way to see that a
request to talk to "192.168.111.0/24" (or whatever) represents traffic that
needs to go out through IPSec. It never talks to Racoon at all.

On 2004-11-27, Sundial Services <(E-Mail Removed)> wrote:
>
> Setkey -DP is interesting:
>
> [snipped]
>
> All zeroes!
>
Thats not the interesting bit, the bits which are interesting are the
'in none' and 'out none' which means you have no ipsec policies configured.
The zero's mean from '0.0.0.0/0' to '0.0.0.0/0' no crypto. Its the default
config.

For me (client to my server) I use (run the file with
'setkey -f /path/to/sa-conf'):

[snip]
#!/usr/sbin/setkey -f

# Flush the SAD and SPD
flush;
spdflush;

## WormNET
spdadd 10.128.10.0/24 10.128.10.0/24 any -P out none;
spdadd 10.128.10.0/24 10.128.10.0/24 any -P in none;
# bitbucket hack
spdadd 10.128.10.1 10.128.0.20 any -P out none;
spdadd 10.128.0.20 10.128.10.1 any -P in none;
# wifi-inskipp - we only do AH as guacmole ain't fast
spdadd 10.128.10.1 0.0.0.0/0 any -P out ipsec
ah/tunnel/10.128.10.1-10.128.10.254/require;
# esp/tunnel/10.128.10.1-10.128.10.254/require;
spdadd 0.0.0.0/0 10.128.10.1 any -P in ipsec
ah/tunnel/10.128.10.254-10.128.10.1/require;
# esp/tunnel/10.128.10.254-10.128.10.1/require;
[/snip]

This is the config I use to convert my wireless gateway into a pure ipsec
only gateway. However as I'm using a good old 50Mhz Sun Lunchbox[1] which
caps out at 100kB/s with ESP (with AH its 300kB/s)[2] I have had to whitelist
our bitbucket, so I get 500kB/s; I do only have an old 11Mbps gateway.

The setup means everything to and from 10.128.10.0/24 is not encrpyted,
however (if we ignore the hacks) everything to the internet (from
10.128.10.1, my address but it must be static) goes through an ipsec tunnel
between 10.128.10.254 to 10.128.10.1. Its important you have a rule for each
direction.

You seem to have none of these polices. As for the routing table, this is
transparent to it. With freeswan you got a virtual interface, with kame (2.6
and racoon) you do not; it simply just does it.

All you can do is really keep an eye on the output of the racoon daemon in
debug mode and have a good read of the IPSec HOWTO[4] as to be frank, I think
you have missed some rather major points :P

> The "ifup-ipsec" command gave "network is unreachable." A query of the
> "route" command shows no routes whatsoever mentioning the VPN
> address-range...
>
> "ping" of the desired address says:
> "Connect: invalid argument."
>
> "ip route get to <<any VPN address>>" shows a perfectly uninteresting route,
> going out the default gateway.
>
As covered above, IPSec with KAME is transparent to the routing table.

Of course I would blame it on your distro DeadRat being a Debian guy myself
:P

Cheers

Alex

[1] http://eintr.net/systems/sun/sparcclassic/
[2] when it maxes out the DNS server on it no longer responses and this is
why I go for AH. Really I have the attitude "if they do not sniff
the traffic here they will further up" so I use ssh/ssl/etc for
sensitive things, the AH just guarentees only people I give a
certificate to can use my wifi gateway. The advantage of this is I
can have MAC locking/WEP disabled and broadcast the ESSID which makes
for a very easy client setup. Of course this needs re'inforcement on
the gateway with firewall rules (hint: the MARK on packets is
maintained over decryption)
[3] http://www.ipsec-howto.org/x247.html

Alexander Clouter wrote:
> All you can do is really keep an eye on the output of the racoon daemon in
> debug mode and have a good read of the IPSec HOWTO[4] as to be frank, I
> think you have missed some rather major points :P

To solve the problem, at this point, I'm looking at purchasing, or renting,
a Windows-2000 machine dedicated strictly to this project for its duration.
This is considerably cheaper than the revenue I've already lost.

I don't deny that "I've missed some rather major points." What I need is
/results/ ... not an unwanted, ill-timed education in the intricacies of
VPN. Time is money and I'm losing a lot of it without compensation.

This is, of course, nothing to do with you or Linux or anything else ... I
am grateful for your ongoing assistance. I love Linux. But it is
despairing, sometimes, how Linux "sends you to school" when you simply want
to push a button and have it be done for you. That's what an OS-vendor is
supposed to be about, in an ideal world, and it's at times like these that
I /really/ feel just how far Linux has to go.

(And this isn't "linux.advocacy," and this isn't flame, so I think we can
leave it at that.)

I have taken your config-file and entered it, carefully adjusting the
entries as appropriate. I continued to leave both 'ah' and 'esp' in the
list although I'm not sure about that.

There are no routing entries.

"Ping" gives me...
connect: invalid argument

When issuing the commands in the shell file, racoon says:
INFO: unsupported PF_KEY message REGISTER

Racoon never seems to actually /do/ anything once it starts up. It's never
initiating any sort of negotiation with anyone.

Sundial Services wrote:
> "Ping" gives me...
> connect: invalid argument

To clarify:

(1) "ping" refuses only for the IP-address range I had previously tried to
map to the VPN.

(2) "ip route get to..." that address-range says:
RTNETLINK answers: invalid argument

(3) Log files give no clues.

<FLAME ON!> I feel like this software is almost playing games with me.
Silly things, like incomprehensible messages if you leave off '-f' on
issuing setkey. Cryptic messages that have no bread-crumbs leading you to
any sort of resolution. A situation that seems quite _content_ to waste
days of what should be /billable/ time ... clearly devised by engineers who
have never worked by-the-hour in their lives. A system that can only
/work/ if you /understand/ it deeply. No wonder Windows and OS/X have been
so successful. </FLAME>

Thank you. I feel much better now.

On 2004-11-28, Sundial Services <(E-Mail Removed)> wrote:
>
> I have taken your config-file and entered it, carefully adjusting the
> entries as appropriate. I continued to leave both 'ah' and 'esp' in the
> list although I'm not sure about that.
>
Well you are free to use either (or both if you uncomment them both and
remove the semi-colon at the end of the first line so it flows as one line).
It depends on your needs of course.

> There are no routing entries.
>
> "Ping" gives me...
> connect: invalid argument
>
> When issuing the commands in the shell file, racoon says:
> INFO: unsupported PF_KEY message REGISTER
>
'modprobe xfrm_user'? Do you also have ipcomp/ah/esp/aes/sha1/etc compiled
as modules?

> Racoon never seems to actually /do/ anything once it starts up. It's never
> initiating any sort of negotiation with anyone.
>
of course you also need to configure racoon.conf to describe the SA's. If
you have not then in your logfiles you will find racoon complaining.

Cheers

Alex

On 2004-11-28, Sundial Services <(E-Mail Removed)> wrote:
> Alexander Clouter wrote:
>> All you can do is really keep an eye on the output of the racoon daemon in
>> debug mode and have a good read of the IPSec HOWTO[4] as to be frank, I
>> think you have missed some rather major points :P
>
> To solve the problem, at this point, I'm looking at purchasing, or renting,
> a Windows-2000 machine dedicated strictly to this project for its duration.
> This is considerably cheaper than the revenue I've already lost.
>
sounds likes someones promised something by a deadline.

> I don't deny that "I've missed some rather major points." What I need is
> /results/ ... not an unwanted, ill-timed education in the intricacies of
> VPN. Time is money and I'm losing a lot of it without compensation.
>
> This is, of course, nothing to do with you or Linux or anything else ... I
> am grateful for your ongoing assistance. I love Linux. But it is
> despairing, sometimes, how Linux "sends you to school" when you simply want
> to push a button and have it be done for you. That's what an OS-vendor is
> supposed to be about, in an ideal world, and it's at times like these that
> I /really/ feel just how far Linux has to go.
>
To do the exact same thing under Windoze you have to do pretty much:

http://ipsec.math.ucla.edu/services/ipsec-windows.html

Now you are doing *exactly* the same under linux/freebsd/etc however its
probably easier as you have everything clearly in two configuration files.
With M$ you have boxes, buttons and windows everywhere and its hard to put
them altogether. Hell I just tried the other week and failed to get windoze
to play ball, it refused to find the certificate I had given it....twice!

There is L2TP+IPSec however that is different and easy to setup under
windoze. If you want pure IPSec, which you should as its more efficient,
then windoze is going to give you a lot of 'excitement' to burn the midnight
oil over.

There is no touchy-feely click'n'drool interface. IPSec is not an easy thing
per-say to just roll out at a click of a mouse button. Certificate
infrastructures do not arrive overnight, however once in place your have a
very powerful system in place with complete control at your fingertips.

From your needs I would highly recommend you go over to CISCO[1] whom will do
this for you, but of course you pay for it, its part of the game; however I
am probably preaching to the choir which is why you are trying to learn/use
Linux.

> (And this isn't "linux.advocacy," and this isn't flame, so I think we can
> leave it at that.)
>
well about this time I would say its time for a beer or at least your
favourite caffinated drink, coffee, black, no sugar.

Regards

Alex

[1] the professionals http://www.cisco.com/edu/peterpacket/
I got the 'QoS Rocket' and had to stop before I killed myself