Project

General

Profile

Issue #3466

routing LAN client traffic through a tunnel - route base IPSEC

Added by amit mulayoff about 1 month ago. Updated 24 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.6.2
Resolution:

Description

I have a scenario which I open an ipsec tunnel Strongswan(initiator) Vs Cisco FlexVPN as a hub (responder).

I'm also using dynamic IP configuration to get tunnel IP address (as in this guide https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp ) from the Cisco hub (ipsec.conf is attached).

Then tunnel is in ESTABLISHED state , but I can't route traffic from the Cisco hub to my linux device via the tunnel.
There is reachability from the Cisco device to the tunnel IP address that was received from Cisco device.
I am using left/right subnets as any/any , and for the example I got Tunnel IP address 30.30.30.6 form Cisco which I put on the VTI device...

In parallel I'm using same setup Cisco Vs Cisco where everything is ok all traffic pass ok.

Some info:
1. In Cisco HUB shows - Virtual-Access1 is the connection to Cisco initiator , Virtual-Access2 is the connection to the Linux device initiator
2. show crypto ikev2 sa detailed:
  • a. In Cisco initiator : Dynamic Route Update: enabled
  • b. In Linux initiator : Dynamic Route Update: disabled
3. In show crypto ipsec sa:
  • a. Cisco initiator Virtual-Access2 remote ident is: (0.0.0.0/0.0.0.0/0/0)
  • b. Linux initiator Virtual-Access2 remote ident is: (30.30.30.6/255.255.255.255/0/0)
4. In Strongswan ipsec statusall:
  • a. The policy was set to leftsubnet=0.0.0.0/0 but shows as: crypto-map-tunnel1_58010001{8724}: 30.30.30.6/32 === 0.0.0.0/0

I can only ping the address that I got form the Cisco and not any other LAN (see Cisco routing table attached)...

please if any one can advice , hope i made my problem clear.

thanks in advance

Cisco_HUB.txt (3.9 KB) Cisco_HUB.txt amit mulayoff, 27.05.2020 10:53
Cisco_HUB_show_crypto_ikev2_sa_detailed.txt (2.36 KB) Cisco_HUB_show_crypto_ikev2_sa_detailed.txt amit mulayoff, 27.05.2020 10:53
Cisco_HUB_show_crypto_ipsec_sa.txt (3.75 KB) Cisco_HUB_show_crypto_ipsec_sa.txt amit mulayoff, 27.05.2020 10:53
ipsec_statusall.txt (2.05 KB) ipsec_statusall.txt amit mulayoff, 27.05.2020 11:13
ipsec_conf_secrets.txt (1.3 KB) ipsec_conf_secrets.txt amit mulayoff, 27.05.2020 11:13
Cisco_route_table.txt (1.78 KB) Cisco_route_table.txt amit mulayoff, 27.05.2020 11:22

History

#1 Updated by Tobias Brunner about 1 month ago

  • Status changed from New to Feedback
  • Priority changed from High to Normal

As you can see in the status output, you negotiated an IPsec policy that only allows traffic from the virtual IP. Traffic from any other IP address won't match and it not tunneled. What's the point of the virtual IP address if you want to simply have a site-to-site tunnel?

#2 Updated by amit mulayoff about 1 month ago

Tobias Brunner wrote:

As you can see in the status output, you negotiated an IPsec policy that only allows traffic from the virtual IP. Traffic from any other IP address won't match and it not tunneled. What's the point of the virtual IP address if you want to simply have a site-to-site tunnel?

Thanks Tobias for the quick response!
regarding what you wrote - I don't want it to be like this , that will allow traffic only form the virtual IP , see ipsec.conf file im using any to any policy....

I need to use virtual ip because I don't know in advance what will be the tunnel address that the "server" will give..
am I missing something?

#3 Updated by Tobias Brunner about 1 month ago

I need to use virtual ip because I don't know in advance what will be the tunnel address that the "server" will give..
am I missing something?

Why do you need a tunnel IP at all if you tunnel one subnet to another?

#4 Updated by amit mulayoff about 1 month ago

above the Tunnel BGP should run base on this address. so I have to work in route base mode to have the tunnel ip for the BGP connection and routes

#5 Updated by Tobias Brunner about 1 month ago

above the Tunnel BGP should run base on this address. so I have to work in route base mode to have the tunnel ip for the BGP connection and routes

So maybe negotiate two CHILD_SAs? One for BGP (with a virtual IP) and one for the actual traffic.

Theoretically, using 0.0.0.0/0 as local traffic selector could work, but depends on how and when traffic selectors are narrowed (with virtual IPs, the responder usually narrows it to that IP, which results in this issue), check the logs for details.

#6 Updated by amit mulayoff about 1 month ago

I can/need to use only one CHILD_SA , if I use Strongswan also as a responder (same config just add rightsourceip=60.60.60.0/24 for example in ipsec.conf)
I see in statusall that it results in 0.0.0.0/0 === 0.0.0.0/0 and traffic can pass , can I "tell" somehow the Cisco not to narrow it ? it is only up to the Cisco to decide ?

I saw this example in cisco site https://www.cisco.com/c/en/us/support/docs/network-management/remote-access/117257-config-ios-vpn-strongswan-00.html

on how to work vs strongswan as a client but I don't fully understand on how I should operate

#7 Updated by Tobias Brunner about 1 month ago

can I "tell" somehow the Cisco not to narrow it ?

No idea.

it is only up to the Cisco to decide ?

If it's the one narrowing the traffic selector, basically yes. While the client could install broader policies (manually or via custom plugin), that won't help if the responder installed narrowed policies and only allows traffic from the virtual IP.

on how to work vs strongswan as a client but I don't fully understand on how I should operate

That does use a virtual IP only, no subnet as local traffic selector and definitely not 0.0.0.0/0.

#8 Updated by amit mulayoff about 1 month ago

thanks Tobias
I'm not sure which side is narrowing the policy.
suppose the strongswan is narrowing the policy , how can I do what you advised regarding install broader policies (manually or via custom plugin) ?

#9 Updated by Tobias Brunner about 1 month ago

I'm not sure which side is narrowing the policy.

As I said before, read the log (cfg on level 2).

suppose the strongswan is narrowing the policy , how can I do what you advised regarding install broader policies (manually or via custom plugin) ?

A custom plugin can implement the narrow hook (see source:src/libcharon/bus/listeners/listener.h#L252) and return whatever traffic selectors it likes to install. Alternatively, manual policy installation is possible by disabling policy installation by strongSwan and then doing that either beforehand or in an updown/vici script via ip xfrm policy.

#10 Updated by amit mulayoff about 1 month ago

A custom plugin can implement the narrow hook (see source:src/libcharon/bus/listeners/listener.h#L252) and return whatever traffic selectors it likes to install. 

maybe you have an example or a manual on how to do this? does it mean compile strongswan by me?
Alternatively, manual policy installation is possible by disabling policy installation by strongSwan and then doing that either beforehand or in an updown/vici script via ip xfrm policy.

do you mean by doing this -> sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1 and set charon.install_routes=0 in strongswan.conf?
and then do manually "ip xfrm policy"?

can I disable narrowing at all somehow?

#11 Updated by Tobias Brunner about 1 month ago

maybe you have an example or a manual on how to do this?

There are a lot of existing plugins.

does it mean compile strongswan by me?

Not necessarily, it's also possible to build plugins out-of-tree (but you require the sources of the version you use so the headers match). An example for such a plugin is this one.

do you mean by doing this -> sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1 and set charon.install_routes=0 in strongswan.conf?

No, please read the documentation. Neither of these options controls whether strongSwan installs policies. In ipsec.conf the option installpolicy can be used to disable it.

can I disable narrowing at all somehow?

It's an integral part of IKEv2. Whether there is any narrowing depends on the configured and negotiated traffic selectors.

#12 Updated by amit mulayoff about 1 month ago

Hi Tobias
I did as you said with log-level cfg 2 and I saw that as I understand the Cisco sends the narrowed policy…:

May 31 14:41:12 charon [4923]: 06[CFG] selecting traffic selectors for other:
May 31 14:41:12 charon [4923]: 06[CFG] config: 0.0.0.0/0, received: 30.30.30.6/32 => match: 30.30.30.6/32

but when I work with Cisco vs Cisco (I don't change the configuration in the Cisco at the center at all)

I see that I have all range of 0.0.0.0/0 == 0.0.0.0/0 without narrowing..
can it be something that strongswan client is / isn't sending ?

thanks and good morning

#13 Updated by Tobias Brunner about 1 month ago

but when I work with Cisco vs Cisco (I don't change the configuration in the Cisco at the center at all)

I see that I have all range of 0.0.0.0/0 == 0.0.0.0/0 without narrowing..

Does the Cisco client actually request a virtual IP?

can it be something that strongswan client is / isn't sending ?

Maybe but it might also just be a Cisco thing (e.g. that the client is configured to ignore the narrowed TS and just install 0.0.0.0/0).

#14 Updated by amit mulayoff 30 days ago

The Cisco initiator does request a virtual IP and configured as negotiated..

I Saw also here : https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp
that

The traffic selectors in swanctl.conf and ipsec.conf (local|remote_ts and left|rightsubnet, respectively) default to the value dynamic or %dynamic, respectively. If virtual IPs are used, this value gets dynamically replaced by the received or assigned virtual IP.
Therefore, no local traffic selector must be configured on the client and no remote traffic selector on the server when using virtual IPs. This ensures the client's traffic selector is correctly narrowed to the assigned virtual IP.

can I make it not "dynamically replaced by the received or assigned virtual IP." ? if I'm the initiator..

#15 Updated by Tobias Brunner 29 days ago

can I make it not "dynamically replaced by the received or assigned virtual IP." ? if I'm the initiator..

Since the responder does the narrowing, no. But as I said previously (comment 9), there are options to install custom policies that are not necessarily based on the received traffic selectors. However, if the peer actually wants to use 0.0.0.0/0 on both ends, why would it narrow the traffic selector in the first place? And does it do that too if the client is a Cisco box.

#16 Updated by amit mulayoff 29 days ago

Hi tobias
while comparing the logs beetwen cisco and strongswan at the server side I came across that the Cisco sends NTERNAL_IP4_SUBNET and
INTERNAL_IP4_NETMASK Attributes that I don't send. which maybe what im looking for? I started configuraing it according to https://wiki.strongswan.org/projects/strongswan/wiki/AttrPlugin but I get

Jun 03 23:41:48 rad charon [6296] : 12[IKE] installing new virtual IP 30.30.30.2
Jun 03 23:41:48 rad charon [6296] : 12[CFG] handling INTERNAL_IP4_SUBNET attribute failed

I add to strongswan.conf :

charon {
install_routes = No
retransmit_tries = 1
install_virtual_ip = No
load_modular = yes
plugins {
attr {
subnet = 0.0.0.0/0
}
}
}

can it help for this case..? why am I failing to send this attr ?

#17 Updated by Tobias Brunner 29 days ago

while comparing the logs beetwen cisco and strongswan at the server side I came across that the Cisco sends NTERNAL_IP4_SUBNET and
INTERNAL_IP4_NETMASK Attributes that I don't send.

These are currently not supported (see #191 and #2185). Both attributes affect the remote traffic selectors according to the RFC (the exact use is not fully defined - in particular combining them). I guess if perhaps INTERNAL_IP4_NETMASK is set to 0.0.0.0 that could also have some effect on the local traffic selector in some weird way (but it mostly means send everything through the tunnel). Or does the Cisco device not do any narrowing if these attributes are requested? (The RFC does not require a request, it's perfectly fine to respond with these if just a virtual IP was requested.) It's also possible that Cisco devices somehow use these attributes as indicator for some proprietary modification of the narrowed local traffic selectors (e.g. ignore the narrowing and switch to route-based tunneling based on the received subnets).

I started configuraing it according to https://wiki.strongswan.org/projects/strongswan/wiki/AttrPlugin but I get

That plugin is for servers to assign attributes to clients. You'd need a custom plugin that requests these attributes (I guess that's optional) and then does something useful if it receives any of them.

#18 Updated by amit mulayoff 28 days ago

thanks
I saw in issue 2185 that Martin Will wrote that the strongswan can send those attrs , can I somehow send it? even with empty values..

and as I understand , I can't use the AttrPlugin because Im initiator? why does it care to send it?

#19 Updated by Tobias Brunner 28 days ago

I saw in issue 2185 that Martin Will wrote that the strongswan can send those attrs , can I somehow send it?

No, that was in #191 and he was referring to the attr plugin, which can send those attributes to clients.

and as I understand , I can't use the AttrPlugin because Im initiator?

Correct, it only provides attributes to clients, it doesn't request/process any.

why does it care to send it?

What do you mean?

#20 Updated by amit mulayoff 28 days ago

I meant that If the server can send , why not as client?

if I understand you , then strongswan can't work vs Cisco FlexVpn as a router? only as a host?

#21 Updated by Tobias Brunner 28 days ago

I meant that If the server can send , why not as client?

Clients don't send these attributes. They may process them if they receive them (they can send empty attributes to explicitly request them, but that's not necessary and does not guarantee such an attribute is returned).

if I understand you , then strongswan can't work vs Cisco FlexVpn as a router? only as a host?

I've no idea what Cisco FlexVPN is or does, so I can't answer that. You'd have to talk to Cisco about this.

#22 Updated by amit mulayoff 28 days ago

I see in dbg massage that the strongswan send

initiating IKE_SA tunnel1_58010001 [4] to 192.168.1.11
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.1.10 [500] to 192.168.1.11 [500] (464 bytes)
received packet: from 192.168.1.11 [500] to 192.168.1.10 [500] (462 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
authentication of '192.168.1.10' (myself) with pre-shared key
establishing CHILD_SA tunnel1_58010001{5}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH CPRQ (ADDR DNS) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 192.168.1.10 [500] to 192.168.1.11 [500] (268 bytes)

if I understand this is a CP request with ADDR,DNS (INTERNAL_IP4_ADDRESS and INTERNAL_IP4_DNS )

I only wrote in ipsec.conf %config4 , how Im sending DNS request?

im asking because maybe I can use it..

#23 Updated by Tobias Brunner 28 days ago

I only wrote in ipsec.conf %config4 , how Im sending DNS request?

That's probably requested by the resolve plugin.

im asking because maybe I can use it..

As I said, you'd have to write a custom plugin to request and process other attributes.

#24 Updated by amit mulayoff 28 days ago

ok , so If I want to build a custom plugin what hook I need to implement ? I see that all hooks in listener.h files that related to Virtual IP are after the IP already assigned , and I need before ?

#25 Updated by Tobias Brunner 28 days ago

ok , so If I want to build a custom plugin what hook I need to implement ?

Attributes are handled via separate interface (attribute_handler_t), not listener_t (maybe have a look at the existing plugins). But you might later need the narrow() hook to change traffic selectors based on received attributes.

#26 Updated by amit mulayoff 28 days ago

why will I need narrow() hook ? I only want to send INTERNAL_IP4_SUBNET attribute to the Cisco server and he in his turn will not narrow TSi at his side..

#27 Updated by Tobias Brunner 28 days ago

why will I need narrow() hook ? I only want to send INTERNAL_IP4_SUBNET attribute to the Cisco server and he in his turn will not narrow TSi at his side..

I asked before if that's the case. Is it?

#28 Updated by amit mulayoff 28 days ago

I 99% sure , this is the only diff from the strongswan and the Cisco initiator.. (they send also APPLICATION_VERSION attribute but I don't think its relevant...)

#29 Updated by Tobias Brunner 28 days ago

I 99% sure , this is the only diff from the strongswan and the Cisco initiator..

As I said before, it might also just be that the client behaves differently. But go ahead and try it out.

(they send also APPLICATION_VERSION attribute but I don't think its relevant...)

I guess the responder could behave differently if it thinks it talks to another Cisco box.

#30 Updated by amit mulayoff 28 days ago

can you please point to me the exact attribute_handler_t hook that i should be implementing?
thanks

#31 Updated by Tobias Brunner 27 days ago

can you please point to me the exact attribute_handler_t hook that i should be implementing?

The enumerator. But just look at the existing handlers for guidance (or modify one of them to request additional attributes).

#32 Updated by amit mulayoff 24 days ago

Hi Tobias

some good news.. I tried to send the INTERNAL_IP4_SUBNET attribute as we discussed but the Cisco server didn't seems to care about it.
after more debugging I saw that the Cisco clinet send as vendor id (43) "Cisco FlexVPN Supported" at IKE SA INIT stage..

I did some "force" at my part at "ike_vendor.c" to send this vendor id and it works!!! tunnel has opened with 0.0.0.0/0 === 0.0.0.0/0

I saw In strongswan.conf that we can only configure strongswan vendor it at "charon.send_vendor_id"
can it be configurable "Cisco FlexVPN Supported" ? how about "Cisco Delete Reason" ?
thanks

#33 Updated by Tobias Brunner 24 days ago

after more debugging I saw that the Cisco clinet send as vendor id (43) "Cisco FlexVPN Supported" at IKE SA INIT stage..

I did some "force" at my part at "ike_vendor.c" to send this vendor id and it works!!! tunnel has opened with 0.0.0.0/0 === 0.0.0.0/0

Interesting. I wonder what sending/seeing that VID entails exactly.

can it be configurable "Cisco FlexVPN Supported" ? how about "Cisco Delete Reason" ?

No, you need a custom plugin for that (or a patch that does it, maybe similar to charon.cisco_unity, which is global, though). "Cisco Delete Reason" is probably not useful as we wouldn't now what to do with such notifies (or whatever else it triggers, maybe similar to Microsoft peers who send proprietary error codes).

#34 Updated by amit mulayoff 24 days ago

ok
in this case then , which custom plugin should I use?

#35 Updated by Tobias Brunner 24 days ago

in this case then , which custom plugin should I use?

custom = you write it yourself :)

#36 Updated by amit mulayoff 24 days ago

yes , I ment if there is any hook that I can implement... :)

#37 Updated by Tobias Brunner 24 days ago

yes , I ment if there is any hook that I can implement... :)

I see, message() where you can add the vendor ID to the plain IKE_SA_INIT request.

Also available in: Atom PDF