Simplified explanation in post #2 with new observations

Hey all,

Lately I have been experimenting with the wonderful IPSEC stack. After a lot of struggling (and passing the various implementations racoon->openswan->strongswan). I managed to get everything working. However, I noticed someting odd whenever I try to redirect the packets. What I try to do is make the packets use another IKE port (instead of the default 500/udp). The relevant firewall configuration is stated below.

The problem in a nutshell (enable port redirection):
- Local connection: Whenever my laptop is inside the same local network as my server (in other words: I'm at home), this succeeds.
- Remote connection: Whenever I try to connect using the internet modem of my phone (mobile internet), this succeeds.
- Remote connection: Whenever my laptop is at school connecting fails. (!)

Whenever I disable port redirection, all three setups succeed. (!)

Conclusion: port redirection makes connecting from school fail. Why?

One thing that is inherently different between the mobile internet connection and the connection from school is that whenever I use the mobile internet, my connection is NAT-ed through a gateway. Hence the local IP of the laptop is different from the source IP the server receives when I use mobile internet. But when I'm at school, this is not the case. The local IP the laptop receives is the one that is 'used' to access the world wide web. So that connection is not NAT-ed, but just forwarded through a gateway.
The above might seem like a possible clue, but I don't see how or why the difference in network architecture could affect this. One would expect that port redirecting fails whenever something else is NAT-ing it as well (so, mobile broadband fails and school succeeds). But the opposite is actually the case.

I have no idea how to proceed. I have no single clue as of why connecting from school fails and why connecting from mobile internet succeeds. Please note, that the entire setup (especially netfilter, ipsec.conf, kernel configuration) on both of my machines is the same in all three situations.

So, I suppose is not an issue with my ipsec.conf or my kernel configuration. If anyone wants these files, please ask and I shall post them.

I will describe my setup now:

Both client and server are running:
- Linux 3.0
- Strongswan 4.5.3
- - tunnel mode
- - ikev2
- - nat traversal (4500/udp) is always used

Server:
Firewall: iptables -A PREROUTING -p udp -m udp --dport 56301 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 500

Client:
Firewall: iptables -A OUTPUT -p udp -m udp --dport 500 -j DNAT --to-destination :56301 --persistent

Packet dump from attempted connection from school:

Server:
This pattern continous indefinitly as the server responds but never receives a reply.

Client (replaced my external ip):
This pattern continous indefinitly as the client tries to reconnect but never receives an answer.

I have the complete raw packet dump if anyone would like to see them.

If you have reached this sentence: thank you for reading this rather lengthy post. =Alpha645=

*Polite bump*

I did some more testing today. I figured out that whenever I use a LAN-cable at school, the laptop is behind a gateway that does NAT (in contrast to connecting wireless to the network). Whenever I try connecting to home with port redirection, it works. So that makes stuff a lot simpler:

The layout:

Strongswan Server --- Home Gateway --- --- --- The Internet --- --- --- University Gateway --- Strongswan Cliënt

- If the University Gateway does NAT on the connection (Connected with cable): Success
- If the University Gateway does not NAT (just forward) on the connection (Connected with wireless): Fail

I also tried to use DNAT instead of REDIRECT at the server, but this does not change the situation.

Your port redirecting is making IKE packets violate your IPsec policy which presumably requires non IKE packets to run over IPsec, causing them to be dropped. The NAT change the source addresses of the IKE packets causing IPsec policy to except.

0 members found this post helpful.

I don't follow you on the following points:

IKE packets are not subject to any IPSEC policy at all. Hence they cannot violate it. And of course non IKE packets are required to run over the tunnel (if those match the policy of course). Which packets do you mean by 'them'? The IKE packets or the non IKE packets?

I don't need NAT to change my source IP in order for IKE packets to be accepted. The server accepts any incoming connection from every ip. No additional NAT needed which changes the source address. It works from other locations, so that is not it.