# IPSec + MSN

## setagllib

I worked out that IPSec issue eventually (had to add a fwd rule to the gateway, but not the client... guess I got confused), and it works great now. Everything nice and encrypted beyond prying eyes.

Except one thing. The MSN protocol. It's encrypted fine, but any login method I attempt to use from any client always somehow does NOT respond to certain incoming bits of the handshake. Example:

```
17:54:45.356764 IP baym-cs293.msgr.hotmail.com.1863 > 192.168.0.143.41219: P 1117:1180(63) ack 423 win 17098 <nop,nop,timestamp 5610492 20662487>

17:54:45.356788 IP 192.168.0.143.41219 > baym-cs293.msgr.hotmail.com.1863: . ack 1180 win 1728 <nop,nop,timestamp 20662753 5610492>
```

Every incoming packet has an outgoing packet, and it's all good. Now switch to the IP which does have IPSec happening:

```
17:55:41.756752 IP 192.168.0.1 > 192.168.0.142: ESP(spi=0x00000202,seq=0x1ad)

17:55:41.756752 IP loginnet.passport.com.https > 192.168.0.142.56352: P 1:1117(1116) ack 133 win 17388 <nop,nop,timestamp 34478083 20718788>

17:55:41.756880 IP 192.168.0.142 > 192.168.0.1: ESP(spi=0x00000201,seq=0x28)

17:55:41.757582 IP 192.168.0.142 > 192.168.0.1: ESP(spi=0x00000201,seq=0x29)

17:55:41.945474 IP 192.168.0.1 > 192.168.0.142: ESP(spi=0x00000202,seq=0x1ae)

17:55:41.945474 IP loginnet.passport.com.https > 192.168.0.142.56352: P 1117:1184(67) ack 337 win 17184 <nop,nop,timestamp 34478086 20719162>
```

Pretty much forever. While something is apparently being sent to the gateway, it is NOT being decoded by tcpdump, and probably not by the gateway either. I have no idea why this happens.

Everything else works very well (HTTP, NFS, SSH, you name it), but MSN is a no go. Even the HTTP login method, and even disabling SSL. It fails in AMSN and GAIM. I have not tried any other clients.

What could the problem be here? Should I try setting incoming and outgoing keys to the same thing? Doesn't sound like it would help, to be honest. Googling didn't turn up much, mostly propaganda about IPSec, SSL, MSN, etc.

Any help appreciated, thanks in advance.

----------

## adaptr

What are you connecting to over IPsec ?

MSN sure as hell doesn't support anything like it...

----------

## setagllib

IPSec is meant to be transparent when it's working, so MSN doesn't need to support it (but it DOES do SSL which is, essentially, one step less hardcore IPSec but with a lot more flexiblity - and nothing in the kernel).

IPSec is meant to be a kernel-level facility for encapsulating packets in a different protocol, encrypting them along the way. I use tunnel mode to allow my wireless laptop to encrypt packets that will be sent out to the net, but the gateway decrypts them first and then forwards out the contents. This works perfectly for everything EXCEPT MSN and I'm at a loss as to why. tcpdump implies to me that packets are being generated and encapsulated but possibly with the wrong key (which makes no sense since everything else works, and ONLY 192.168.0.142 is set to encapsulate - and the gateway of course, but that's not having this problem) which would explain why neither tcpdump itself nor the gateway know what to make of it.

----------

## setagllib

Absolutely no ideas?

I'll throw more information at the problem.

Kernel: 2.6.11-gentoo-r4

----------

## setagllib

Seriously no help at all? This is so unlike all the other threads I've seen. If anyone needs more information, please just ask.

----------

## setagllib

I tried a HTTP proxy, that let me log in and get lists, and initially set up conversations... but they drop out instantly. Really confusing and annoying, MSN still entirely useless.

This is a tinyproxy (or AMSN) problem, though, since it happens even without IPSec. So now I'm really stuck.

The logs show it completely normally closing connections as if it was intentional. I suppose HTTP is not a good method for this kind of thing.

----------

## adaptr

Well, I use a HTTP proxy (Kerio WinRoute) to connect at work, and although slow it works perfectly fine...

Sorry  :Wink: 

----------

## setagllib

Argh. Well, I'm ticked off. Trying to use Squid fails because it aborts one second in to running (even on default config, and tested x86 squid).

Has anyone else used the MSN protocol at an IPSec tunnel endpoint?

----------

## adaptr

Is that HTTP proxy at your end of the tunnel or the other end ?

How is routing / NAT setup on the tunnel ?

----------

## setagllib

The proxy is on the gateway's end (makes no sense to have it here, right? HTTP login already failed).

NAT is simple, just a -j POSTROUTING. That's not giving me any problems.

It's really unusual to say the least. I don't know if it happens the same with any BSD systems, but I'd be willing to bet it wouldn't - weird shit like this is a Linux trademark.

----------

## setagllib

I KNEW IT WAS LINUX

I installed DragonFly BSD on the server instead and it works perfectly. So much effort wasted over a heap of !#@% that offers no useful advantages.

Hey everyone, stop using Linux, it can't even do IPSec properly. What a joke kernel. I don't care if this is fixed in .12, that it has been broken this long in a stable branch says a lot about the development process.

----------

## Redhatter

Which Kernel sources are you using? (or rather, were you using??)

Have you considered taking this upstream?

Running to *BSD of course is one option.... but it would be nice if we could fix the bug too  :Smile: 

In fact, let's start at grass roots here...

What OS combinations have you tried on both the client end and gateway?

What's the network topology look like?

Are the routing tables in order?  (I realise you mention everything *except* MSN works, which would suggest they are fine, but it doesn't hurt to double check)

----------

## setagllib

I will explain why I believe this can only be a Linux ipsec bug (possibly fixed, a lot has been changed to ipsec in 2.6.12):

-All routing is fine (since it works perfectly if there is no ipsec happening)

-Packet filtering is fine (even allowing everything doesn't help here, the packets just vanish)

-Network topology couldn't be easier (relevant to this problem, lappy->gateway->internet, and it doesn't matter how the machines are linked - if there is an ipsec tunnel, MSN won't work)

-EXACT SAME ipsec.conf used in the Linux rig as in the DragonFly rig, not a single change, yet in DragonFly it all works as expected.

If I ever happen to run Linux on a gateway again, I'll let you know if the bug is fixed, but otherwise my hopes aren't up.

And hey Redhatter, I keep forgetting you're also a Gentoo Forums member. I don't come here much.

Update: NetBSD 3.0-beta also works perfectly. In fact it's encrypting and routing these packets now.

----------

