Project

General

Profile

Issue #1247

routing not possible/ ipsec0 interface not present

Added by Darko Kraus over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.3.5
Resolution:
No change required

Description

Hi everyone,

I was able to successfully configure connections between the two sites but I have no idea how to route the traffic. My previous experience with FreeSWAN was that it has ipsec0 interface which was used for incoming and outgoing traffic but what is the interface used in the StrongSWAN?

IPsec statusall output:

Connections:
site2: 10.5.224.10...10.5.224.13 IKEv1
site2: local: [10.5.224.10] uses pre-shared key authentication
site2: remote: [10.5.224.13] uses pre-shared key authentication
site2: child: 192.168.2.0/24 === 192.168.3.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
site21: ESTABLISHED 15 seconds ago, 10.5.224.10[10.5.224.10]...10.5.
224.13[10.5.224.13]
site21: IKEv1 SPIs: 14887c6e5ea9fe1c_i* 2cedb1c19470891a_r, pre-shared
key reauthentication in 7 hours
site21: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
site2{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c21cace2_i c2ca41ad_o
site2{1}: 3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 109 m
inutes
site2{1}: 192.168.2.0/24 === 192.168.3.0/24

The routing table:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.240.2.1 0.0.0.0 UG 0 0 0 eth2
10.5.224.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

There is no routing to 192.168.3.x network.

Any help would be greatly appreciated!!!

History

#1 Updated by Noel Kuntze over 4 years ago

Hello Darko,

Please read the introduction and the article about forwarding before working with the software.

strongSwan builds policy based tunnels, not route based ones.

#2 Updated by Darko Kraus over 4 years ago

Hello and thank you for the reply. I read the introduction and the forwarding article, what I have discovered is the strongswan IPsec comes up it created a rule called "220". Once the tunnel for a particular site comes up it puts a route in that policy table so in my case, executed on the remote site, it shows:

root@micka:~# ip route show table 220
192.168.2.0/24 via 10.5.224.10 dev eth1 proto static src 192.168.3.1

I am able to ping back and forth and there is flow of traffic (both tcp and udp). On my previous setups I was using ipsec0 interface where all unencrypted traffic would flow in and out and was able to set iptables. I am not very clear on how to create a firewall rules to restrict certain traffic. Using tcpdump to see what comes and out, for a single ping from a remote site I get this:

18:13:28.721434 IP 10.5.224.10 > 10.5.224.13: ESP, length 152
18:13:28.721486 IP 192.168.2.2 > 192.168.3.5: ICMP echo request, id 1212, seq 1, length 64
18:13:28.721911 IP 10.5.224.13 > 10.5.224.10: ESP, length 152

What this tells me is that remote traffic comes in encrypted (ESP) on eth1. It gets decrypted and comes in once again through the same interface (ICMP). Reply comes out eth1 encrypted as it should.

The parts I don't understand is that unencrypted traffic comes in on eth1 after being decrypted. I don't think this is a good thing, and I am concerned about security issues with it.

My current rules block any local traffic (192.168.x.x/16) coming from eth1, so this would violate the firewall rules and I would have no traffic. What would be the correct replacement for the way to filter traffic like the old ipsec0 interface? In other words can you give me an example of the firewall policy that would be as secure as using the old ipsec0 interface?

Thank You!!!

#3 Updated by Noel Kuntze over 4 years ago

The parts I don't understand is that unencrypted traffic comes in on eth1 after being decrypted. I don't think this is a good thing, and I am concerned about security issues with it.

There's no issue with that. The kernels drop unencrypted packets that are supposed to be secured with IPsec.

What this tells me is that remote traffic comes in encrypted (ESP) on eth1. It gets decrypted and comes in once again through the same interface (ICMP). Reply comes out eth1 encrypted as it should.

That's known. Look at the tutorial for taking traffic dumps

My current rules block any local traffic (192.168.x.x/16) coming from eth1, so this would violate the firewall rules and I would have no traffic. What would be the correct replacement for the way to filter traffic like the old ipsec0 interface? In other words can you give me an example of the firewall policy that would be as secure as using the old ipsec0 interface?

Use the "policy" match module of iptables and/or look at the firewall rules in the updown script (called _updown), wherever your distribution put it. It can insert iptables rules to allow traffic, if it's enabled using leftfirewall=yes.

#4 Updated by Darko Kraus about 4 years ago

I used the leftfirewall=yes and I noticed the iptables rules inserted, but this might cause problems too:

On my main firewall I have the following iptables rules:

iptables -A INPUT -j DROP -i eth2 -p all -s 10.0.0.0/8 -d 0/0
iptables -A INPUT -j DROP -i eth2 -p all -s 172.16.0.0/12 -d 0/0
iptables -A INPUT -j DROP -i eth2 -p all -s 192.168.0.0/16 -d 0/0

This blocks spoofed traffic claiming It is from local networks that comes in on eth2 (eth2 being external interface. How can I use the IPsec with these rules? To me looks one of these rules would block any traffic coming in from my valid IPsec tunnel.

I have also tried to use the tcpdump and reading the article on the page suggested, but I get:

tcpdump: WARNING: SIOCGIFADDR: nflog:5: No such device
tcpdump: packet printing is not supported for link type NFLOG: use -w

Thank you for the quick responses!!!

#5 Updated by Noel Kuntze about 4 years ago

This blocks spoofed traffic claiming It is from local networks that comes in on eth2 (eth2 being external interface. How can I use the IPsec with these rules? To me looks one of these rules would block any traffic coming in from my valid IPsec tunnel.

Usually, the rpfilter (reverse path filzer) is enabled on Linux, which prevents IP spoofing on that level. Your rules are badly implemented, please look at the rpfilter module for iptables if you want to do do a real effort or remove those rules completely. The routes that strongswan inserts into table 220 will allow traffic through the rpfilter just fine. Look at the man page for `iptables-extensions`, specifically the part about the "policy" match module. That module allows you to match IPsec protected traffic.

I have also tried to use the tcpdump and reading the article on the page suggested, but I get:

tcpdump: WARNING: SIOCGIFADDR: nflog:5: No such device
tcpdump: packet printing is not supported for link type NFLOG: use -w

Please look at the example iptables rules in the article I mentioned. You need to have a matching nflog rule that creates the multicast group to be able to listen to it using tcpdump. If you did that and the error persists, it is plausible that that particular version from the distribution is compiled without support for nflog.

#6 Updated by Darko Kraus about 4 years ago

I do have rp_filter enabled, and as an extra assurance I always block local IPs seen on the interface facing the internet. I am pretty sure my provider blocks all 10.0.0.0/8 172.16.0.0/12 and 192.168.0.0/16 IPs but just in case something sneaks through, I like to have those blocking rules. I think it is a good idea to block these subnets coming from the internet interface:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
127.0.0.0/8
255.0.0.0/8
for IPv4, and for IPv6:
  1. Link-local, old Site-Local, Unique Local Addresses and Multicast
    ip6tables -A INPUT -j DROP -i sixbone -s fe80::/10 -d ::/0
    ip6tables -A INPUT -j DROP -i sixbone -s fec0::/10 -d ::/0
    ip6tables -A INPUT -j DROP -i sixbone -s fc00::/7 -d ::/0
    ip6tables -A INPUT -j DROP -i sixbone -s ff00::/8 -d ::/0

Correct me if I am wrong, I have been using this approach for years for in my home and work network. I am open to any new suggestions.

As far as NFLOG, I have followed the instructions and inserted those iptables rules and recompiled the kernel 3.14.58 to include the required configuration for the IPsec as described here: https://wiki.strongswan.org/projects/strongswan/wiki/KernelModules.
Which of the kernel configuration directives needs to be enabled to include the NFLOG module? Maybe I have missed it somehow.

Thank You!!!

#7 Updated by Noel Kuntze about 4 years ago

I do have rp_filter enabled, and as an extra assurance I always block local IPs seen on the interface facing the internet. I am pretty sure my provider blocks all 10.0.0.0/8 172.16.0.0/12 and 192.168.0.0/16 IPs but just in case something sneaks through, I like to have those blocking rules. I think it is a good idea to block these subnets coming from the internet interface:

That's certainly a good idea if you don't trust your provider and any intermediate entity to do that, however those rules drop any packet, not just unencrypted ones (e.g. ones that are protected with IPsec). You probably want to fix your syntax:
  • -d ::/0 is the same as omitting -d completely
  • The target of iptables rules are usually written at the end.
    A correctly formatted rule would thus be:
    ip6tables -A INPUT -i sixbone -s fe80::/10 -j DROP

fe80::/10 is link-local traffic, by the way. That will never be routed. You can only reach hosts in your broadcast domain over it.
It's used for NDP (the neighbor detection protocol) in IPv6 and necessary for the analogon to ARP (address resolution problem), so by completely
blocking fe80::/10, you potentially break important functionality of IPv6.

IPsec protected packets pass through Netfilter twice, if they are decrypted on the local machine:
  • As encrypted and protected packet envelope
  • As decrypted and unprotected payload

With XFRM and policy based IPsec, that means that packets will be dropped by your iptables rules.
An improvement to that would be to include a policy match that only matches if there is no matching and valid XFRM policy or state
for that packet:
ip6tables -A INPUT -i sixbone -s fe80::/10 -m policy --pol none --dir in -j DROP
Look at the updown script to figure out how to adapt it or, as mentioned before, read the man page for @iptables-extensions`.

NFLOG is not IPsec specific, so it's not mentioned there. I can't tell you, without googling, what module it is, but as I said, it's probably a missing feature in your version of tcpdump. You probably could insert the rule using nflog just fine, so it's not a problem with a missing kernel module.

EDIT: After looking for the module, it's probably nfnetlink_log.

#8 Updated by Darko Kraus about 4 years ago

Thank you for the update.

I guess one of the reasons I use iptables -A INPUT -j ACCEPT, etc instead of putting the -j <target> has to do with the days of ipfwadm (Linux kernel 2.0) when it used to be that way, so since ipchains and iptables do not really care, it makes it easier to see in the firewall scripts (I don't use X-window system with my firewall but pure Linux text-based), which it limited to 80-character width. But yes, I have seen everyone used -j at the end and I have seen many articles using it as well...

As far as IPv6, I agree fe80::/10 being link-local and important address for protocol communication, but you can also use fe80:: address to access a device, so not blocking it, means that the other hosts on the network could access all the services on my router/firewall. I prefer the method of blocking it all, and then allowing only what is needed.

The part that I don't understand very clearly is where there is no interface (in the old days ipsec0 or similar) that all the tunneled packets would come out of, or go into. In my opinion it would make more sense to have an interface for that purpose. I work with Palo Alto Networks firewalls, which are pretty much the top end, and they also use the idea of tunnel.1 tunnel.2 etc for tunneled packets. With all this, is it possible to have the strongswan attach to either a dummy, tunl0 or any other interface inside of the kernel (just like the old ipsec0). I just think that is the way to go.

If there is absolutely no way to use tunl0 or ipsec0 or whatever other device kernel offers, how can I restrict the access to resources through the tunnel?

I have the following:
iptables -A FORWARD -j sm0-hy0 -i eth2 -o eth0 -s 172.16.0.0/16 -d 192.168.2.0/24 -m policy --dir in --pol ipsec --proto esp

From what I understand, the rule above should be passing all the IPsec traffic to the target called sm-hy0. sm-hy0 is listed here:

iptables -N sm0-hy0
iptables -F sm0-hy0
iptables -A sm0-hy0 -j ACCEPT -p tcp -d 192.168.2.4 --dport 21
iptables -A sm0-hy0 -j ACCEPT -p tcp -d 192.168.2.4 --dport 22
iptables -A sm0-hy0 -j ACCEPT -p tcp -d 192.168.2.4 --dport 23
iptables -A sm0-hy0 -j DROP -p all -d 192.168.2.4

I am able to connect to port 25 on host 192.168.2.4 from 172.16.32.18. How is that possible? So in my case 192.168.2.0/24 is my trusted network and 172.16.0.0/16 is SITE2, but not 100% trusted and only certain connections are allowed.

Thank you once again for all the support and help!!!

#9 Updated by Noel Kuntze about 4 years ago

I guess one of the reasons I use iptables -A INPUT -j ACCEPT, etc instead of putting the -j <target> has to do with the days of ipfwadm (Linux kernel 2.0) when it used to be that way, so since ipchains and iptables do not really care, it makes it easier to see in the firewall scripts (I don't use X-window system with my firewall but pure Linux text-based), which it limited to 80-character width. But yes, I have seen everyone used -j at the end and I have seen many articles using it as well...

So do I. I just use iptables-save and pipe that into `less`. Problem solved. You should use `less` to view anything anyway, so it's not really a news.

As far as IPv6, I agree fe80::/10 being link-local and important address for protocol communication, but you can also use fe80:: address to access a device, so not blocking it, means that the other hosts on the network could access all the services on my router/firewall. I prefer the method of blocking it all, and then allowing only what is needed.

Nobody says that you have to allow anything from fe80::/10. Just only allow icmpv6.

With all this, is it possible to have the strongswan attach to either a dummy, tunl0 or any other interface inside of the kernel (just like the old ipsec0). I just think that is the way to go.

There are VTIs, but VTIs are whacky, because some devs break them regularely and they only were relatively recently made functional in the kernel. I can't and won't help you building tunnels with VTIs. There's an article by endre about VTIs. Read and understand what it does before deploying it.

If there is absolutely no way to use tunl0 or ipsec0 or whatever other device kernel offers, how can I restrict the access to resources through the tunnel?

As I mentioned before two times, you can, should and have to use the "policy" match module of iptables to match traffic that is or was decrypted on the local machine.
That module also allows you to match on the IPsec endpoint's IP address.

I am able to connect to port 25 on host 192.168.2.4 from 172.16.32.18. How is that possible?

You obviously allowed it. I have no idea what traffic you put into the "sm0-hy0" chain. Just only put traffic from that one endpoint and/or IP subnet into the chain from which that traffic should be allowed.

#10 Updated by Darko Kraus about 4 years ago

So after several days modifying my firewall scripts I have made the strongswan successfully working between the two sites using PSK. One of the issues I had was packets generated from my local-net toward remote site were getting NATed, so there are two approached to overcome that issue:
One was to add a rule:
iptables -A PREROUTING -t raw -j NOTRACK -i eth0 -s 192.168.2.0/16 -d 172.16.0.0/16

which does not track packets but allows communication from my localnet (192.168.2.x) to the remote site (172.16.x.x).

OR the second way was to add -m policy --pol none:
iptables -A POSTROUTING -s 192.168.2.0/24 -o eth2 -m policy --dir out --pol none -j SNAT --to-source $PUBLIC_IP0

Later on, NOTRACK became a small problem so my final rules are:

iptables -A FORWARD -j loclan0-IPSec -i eth0 -o eth2 -s 192.168.0.0/16 -d 0/0 -m policy --dir out --pol ipsec --reqid 1 --proto esp
iptables -A FORWARD -j remlan0-loclan0 -i eth2 -o eth0 -s 172.16.0.0/16 -d 192.168.2.0/24 -m policy --dir in --pol ipsec --reqid 1 --proto esp
(eth0 being my local interface and eth2 the one facing the internet side).

Now there are some things I have to say.
I have been using IPsec developed by FreeSWAN back in the 2000 days and have been working very well for years, but as the project was dead back in 2004, I had choices between strongswan and openswan (liberswan). The first great impression is this website which shows that someone took the time to write all this up and that is a major PLUS! I am not a programmer at all, but the part I don't understand is if someone can give me a good reason why we are using IPsec policies and there is no ipsec0 or whatever interface present. As a fact I know Cisco and Palo Alto Networks firewalls both use the concept of "tunneling device". Why is the same not being used with this software? Is there any plan in the future to implement it in the future releases?

One reason why I was able to connect to port 25 on host 192.168.2.4 when it was denied by the chain in the previous post, is because the IPsec packets were using the rules that were allowing NAT hosts, since both packets come in on eth2 (external) interface.

I have looked at the vti's and I see my kernel already had a device called vti0:
9: ip_vti0@NONE: <NOARP> mtu 1428 qdisc noop state DOWN
link/ipip 0.0.0.0 brd 0.0.0.0

but I have not attempted to mess with it yet.

One question that I still have that is very unclear to me is the option "--reqid 1" and what it does in the iptables? Can it be omitted?

Again thank you for all your help!!!

#11 Updated by Noel Kuntze about 4 years ago

I am not a programmer at all, but the part I don't understand is if someone can give me a good reason why we are using IPsec policies and there is no ipsec0 or whatever interface present. As a fact I know Cisco and Palo Alto Networks firewalls both use the concept of "tunneling device". Why is the same not being used with this software? Is there any plan in the future to implement it in the future releases?

ipsec0 devices aren't route based tunnels, they're actually policy based tunnels, which are presented as interfaces, as far as I know. That means that you can only send traffic through the device that is also allowed by the IPsec policies that were negotiated. Only traffic that is sent through the interface is subject to IPsec encapsulation.
XFRM works the same way, but without the device. This means that any traffic that matches a policy is subject to XFRM processing, if it is not denied by a passthrough policy.
Policy based tunnels were integrated earlier than route based ones. Route based ones are, compared to policy based ones, fairly new. VTIs are also only really stable in newer kernels.
I do not remember any new request for VTI support in strongSwan and I think it's something that users should set up, if they want it, by themselves. The scripts are available and doing it (by scripting it in the updown script) isn't really difficult. I can not say anything about any future support. This is up to the devs and/or any sponsor willing to pay for native support for it.

I have looked at the vti's and I see my kernel already had a device called vti0:
9: ip_vti0@NONE: <NOARP> mtu 1428 qdisc noop state DOWN
link/ipip 0.0.0.0 brd 0.0.0.0

I think that's the standard one, I never messed with it. I think you should create a new one for yourself to make sure it has the properties you require.

One question that I still have that is very unclear to me is the option "--reqid 1" and what it does in the iptables? Can it be omitted?

The reqid is a field in the IPsec SA (or SP?, unclear to me) in the SAD or SPD. You can match on it to make sure only traffic matching that specific SA/SP is matched and processed by the iptables rules. The reqid is not conveyed in an ESP/AH packet. You can't match on it in incoming traffic, only outgoing traffic.

#12 Updated by Darko Kraus about 4 years ago

I think it made more sense to send the tunnel traffic to the specific tunnel interface then out the internet interface. Just like ipv6 is setup, it has its own sit device and when I setup the firewall I expect all the IPv6 traffic to appear on the sit device and the protocol 41 just passes through the external interface (in my case eth2). But at least I was able to get everything to work correctly with your help so I do appreciate it!

I have several more questions regarding different scenarios such as using rsasigkey and connection from a mobile device (android phone) and establishing an IPsec tunnel using strongswan client provided or native android client.

The first scenario, I followed the instructions provided here: https://www.strongswan.org/testing/testresults4/ikev2/net2net-rsa/index.html
Here are my configuration file on the remote router where the connection is initiated:

/etc/ipsec.conf:

conn default
keyexchange = ikev2
keylife = 2h
rekeymargin = 8m
rekeyfuzz = 30

ikelifetime = 8h
keyingtries = 5
esp = aes192-sha256-modp2048
ike = aes192-sha256-modp2048

conn site1
left = 5.5.224.13
leftsubnet = 192.168.3.0/24
leftid = 5.5.224.13
leftrsasigkey = MIIBIjANBgkq... (RSA pubkey of the localhost)
leftauth = pubkey
leftfirewall = no
right = 5.5.224.10
rightsubnet = 192.168.5.0/24
rightid = 5.5.224.10
rightrsasigkey = MIIBIjANBgk... (RSA pubkey of the remote router)
rightauth = pubkey

/etc/ipsec.secrets:

: RSA mickaKey.pem (mickaKey.pem was created using 'openssl genrsa 2048'. The file is located in /etc/ipsec.d/private and has permission rw------)

The remote site has a very similar configuration with the two rsaleft and right sigkeys swapped around.

When I try to bring the connection up from 5.5.224.13 I get the following:

root@micka:/etc# ipsec up site1
initiating IKE_SA site13 to 5.5.224.10
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG
) ]
sending packet: from 5.5.224.13500 to 5.5.224.10500 (684 bytes)
received packet: from 5.5.224.10500 to 5.5.224.13500 (456 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N
(MULT_AUTH) ]
no private key found for '5.5.224.13'
establishing connection 'site1' failed

I am not sure what I am missing here? I have also tried converting the private rsa key to the DER format using 'openssl rsa -in mickaKey.pem -inform PEM -out mickaKey.der -outform DER'
But no luck, still the same message appears.

#13 Updated by Darko Kraus about 4 years ago

Darko Kraus wrote:

I think it made more sense to send the tunnel traffic to the specific tunnel interface then out the internet interface. Just like ipv6 is setup, it has its own sit device and when I setup the firewall I expect all the IPv6 traffic to appear on the sit device and the protocol 41 just passes through the external interface (in my case eth2). But at least I was able to get everything to work correctly with your help so I do appreciate it!

I have several more questions regarding different scenarios such as using rsasigkey and connection from a mobile device (android phone) and establishing an IPsec tunnel using strongswan client provided or native android client.

The first scenario, I followed the instructions provided here: https://www.strongswan.org/testing/testresults4/ikev2/net2net-rsa/index.html
Here are my configuration file on the remote router where the connection is initiated:

/etc/ipsec.conf:

conn default
keyexchange = ikev2
keylife = 2h
rekeymargin = 8m
rekeyfuzz = 30

ikelifetime = 8h
keyingtries = 5
esp = aes192-sha256-modp2048
ike = aes192-sha256-modp2048

conn site1
left = 5.5.224.13
leftsubnet = 192.168.3.0/24
leftid = 5.5.224.13
leftrsasigkey = MIIBIjANBgkq... (RSA pubkey of the localhost)
leftauth = pubkey
leftfirewall = no
right = 5.5.224.10
rightsubnet = 192.168.5.0/24
rightid = 5.5.224.10
rightrsasigkey = MIIBIjANBgk... (RSA pubkey of the remote router)
rightauth = pubkey

/etc/ipsec.secrets:

: RSA mickaKey.pem (mickaKey.pem was created using 'openssl genrsa 2048'. The file is located in /etc/ipsec.d/private and has permission rw------)

The remote site has a very similar configuration with the two rsaleft and right sigkeys swapped around.

When I try to bring the connection up from 5.5.224.13 I get the following:

root@micka:/etc# ipsec up site1
initiating IKE_SA site13 to 5.5.224.10
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG
) ]
sending packet: from 5.5.224.13500 to 5.5.224.10500 (684 bytes)
received packet: from 5.5.224.10500 to 5.5.224.13500 (456 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N
(MULT_AUTH) ]
no private key found for '5.5.224.13'
establishing connection 'site1' failed

I am not sure what I am missing here? I have also tried converting the private rsa key to the DER format using 'openssl rsa -in mickaKey.pem -inform PEM -out mickaKey.der -outform DER'
But no luck, still the same message appears.

Edit: Ok the issue was that either 0s or 0x prefix needs to added to the pubkeys in ipsec.conf file for each peer. That fixed the problem.

#14 Updated by Jeff W about 4 years ago

Hi Darko,

I was setting up a tunnel using the net2net-rsa example[[https://www.strongswan.org/uml/testresults5/ikev2/net2net-rsa/index.html]]. I have the "no private key found" problem as well. But I did use the "0s" prefix. Can you tell me how the RSA pubkeys were extracted from the private keys?

Thanks!

Darko Kraus wrote:

Darko Kraus wrote:

I think it made more sense to send the tunnel traffic to the specific tunnel interface then out the internet interface. Just like ipv6 is setup, it has its own sit device and when I setup the firewall I expect all the IPv6 traffic to appear on the sit device and the protocol 41 just passes through the external interface (in my case eth2). But at least I was able to get everything to work correctly with your help so I do appreciate it!

I have several more questions regarding different scenarios such as using rsasigkey and connection from a mobile device (android phone) and establishing an IPsec tunnel using strongswan client provided or native android client.

The first scenario, I followed the instructions provided here: https://www.strongswan.org/testing/testresults4/ikev2/net2net-rsa/index.html
Here are my configuration file on the remote router where the connection is initiated:

/etc/ipsec.conf:

conn default
keyexchange = ikev2
keylife = 2h
rekeymargin = 8m
rekeyfuzz = 30

ikelifetime = 8h
keyingtries = 5
esp = aes192-sha256-modp2048
ike = aes192-sha256-modp2048

conn site1
left = 5.5.224.13
leftsubnet = 192.168.3.0/24
leftid = 5.5.224.13
leftrsasigkey = MIIBIjANBgkq... (RSA pubkey of the localhost)
leftauth = pubkey
leftfirewall = no
right = 5.5.224.10
rightsubnet = 192.168.5.0/24
rightid = 5.5.224.10
rightrsasigkey = MIIBIjANBgk... (RSA pubkey of the remote router)
rightauth = pubkey

/etc/ipsec.secrets:

: RSA mickaKey.pem (mickaKey.pem was created using 'openssl genrsa 2048'. The file is located in /etc/ipsec.d/private and has permission rw------)

The remote site has a very similar configuration with the two rsaleft and right sigkeys swapped around.

When I try to bring the connection up from 5.5.224.13 I get the following:

root@micka:/etc# ipsec up site1
initiating IKE_SA site13 to 5.5.224.10
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG
) ]
sending packet: from 5.5.224.13500 to 5.5.224.10500 (684 bytes)
received packet: from 5.5.224.10500 to 5.5.224.13500 (456 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N
(MULT_AUTH) ]
no private key found for '5.5.224.13'
establishing connection 'site1' failed

I am not sure what I am missing here? I have also tried converting the private rsa key to the DER format using 'openssl rsa -in mickaKey.pem -inform PEM -out mickaKey.der -outform DER'
But no luck, still the same message appears.

Edit: Ok the issue was that either 0s or 0x prefix needs to added to the pubkeys in ipsec.conf file for each peer. That fixed the problem.

#15 Updated by Darko Kraus about 4 years ago

Hi Jeff,

I was using the following commands:

To generate the RSA private key:
openssl genrsa -out gateway.key 2048

You can use options such as -des3 or -aes128 before 2048 to encrypt your key if you would like but that requires that you supply the encryption password to the line next to the key such as: RSA : gateway.key "password"

If you wish you can rename the key file to gatewayKey.pem as instructed in the strongswan wiki.

Put that private key in the folder /etc/ipsec.d/private

To extract the private key use the following commands:

openssl rsa -in /etc/ipsec.d/private/gateway.key -pubout -out pubkey.pem

The file pubkey.pem would contain public key based on your private key.

Make sure to add 0s in front of that long string of the pubkey.

Hope this helps...

#16 Updated by Tobias Brunner about 4 years ago

  • Category changed from interoperability to configuration
  • Status changed from New to Closed
  • Resolution set to No change required

Also available in: Atom PDF