topic Re: IPsec problem in Security e-Series

IPsec problem

pattap — Thu, 28 Jul 2016 11:49:19 GMT

Hi All

I've set up an IPsec tunnel between two sites

site A two vlans: 10.10.11.0/24 and 10.10.12.0.24

ospf switch A: network vlan 100 ip, network 10.10.11.0/24, network 10.10.12.0/24, stub

site B acts as a gateway for users on switch A.

ospf switch B: network vlan 100 ip, stub no-summary default-route-advertise-always

switch a -------vlan 100 ospf p2p ---------- switch b

ACL on switch A that I've used for IPsec policy

acl 3030

rule 0 permit ip source 10.10.11.0 0.0.0.255 dest any

rule 5 permit ip source any dest 10.10.11.0 0.0.0.255

rule 10 permit ip source 10.10.12.0 0.0.0.255 dest any

rule 15 permit ip source any dest 10.10.12.0 0.0.0.255

switch B

rule 0 permit ip source any dest 10.10.11.0 0.0.0.255

rule 5 permit ip source 10.10.11.0 0.0.0.255 dest any

rule 10 permit ip source any dest 10.10.12.0 .0.0.0.255

rule 15 permit ip source 10.10.12.0 0.0.0.255 dest any

Now the issue is that none of the ACL is hit by traffic coming from two local VLANS on switch A. If I source traffic from one switch to another I can see ike sa and ipsec sa being created but again traffic from those two lans won't be encrypted, what am I missing here?

Re: IPsec problem

user115 — Fri, 29 Jul 2016 08:04:09 GMT

Hi!

Your description is a bit confusing, so, I'll try to answer according to what I believe you have meant.

Do you have those networks you want to encrypt added to ospf process? If yes, you should set up the GRE over IPSEC tunnel and just encrypt traffic between two peers using acl that just encrypts GRE protocol between peer 1 and peer 2. Then apply OSPF to tunnel interfaces, so traffic would be routed by OSPF and encrypted when flowing out the GRE interface.

If those networks are not added to OSPF process then... Then what did you set up OSPF for? IPSEC will automatically inject routes to kernel after the IPSEC SA will be set up, adding remote site networks directly to the routing table (though they might not be visible, it's ok). So you can just set up the connection between two sites (static route, L2, BGP, whatever you use just for peers to be able to access each other) and create IPSEC tunnel with needed params and traffic will flow.

P.S. You don't need to specify the response traffic in your encyption ACL.

acl 3030

rule 0 permit ip source 10.10.11.0 0.0.0.255 dest any

rule 10 permit ip source 10.10.12.0 0.0.0.255 dest any

it would be enough for site A to encrypt the traffic you need.

Re: IPsec problem

user115 — Fri, 29 Jul 2016 08:07:51 GMT

Oops, sorry, I meant acl should be:

acl 3030

rule 0 permit ip source 10.10.11.0 0.0.0.255 dest <your_remote_network>

rule 10 permit ip source 10.10.12.0 0.0.0.255 dest <your_remote_network>

Mirror it on the other side.

Re: IPsec problem

pattap — Fri, 29 Jul 2016 14:40:09 GMT

sorry for not being clear enough, ok some more details:

core(5800): g1/0/26 <--- vlan 4000 ospf area 0 p2p ---> g1/0/25 HP3600A g1/0/25 <---vlan 4036 ospf area 15 p2p ---> g1/0/25 HP3600B ---->local VLAN 10

vlan 10 - 10.10.10.0/24

now I want all the traffic coming out of HP3600B to be encrypted hence I was using permit ip source 10.10.10.0/24 dest any and at HP3600A end permit ip source any dest 10.10.10.0 /24

all the interface vlans between devices are participating in ospf

ospf config on HP3600A

ospf 1

area 0

net vlan 4000

area 15

net vlan 4036

stub no-summary default-route-advertise-always

ospf config on HP3600B

ospf 1

silent int vlan 10

area 15

net vlan 4036

net vlan 10

stub

my IPsec policy is applied on interfaces vlan 4036 on HP3600A and B

and like I mentioned before ACL is not being hit by traffic going out of the vlan 10 or coming into it

Re: IPsec problem

pattap — Fri, 29 Jul 2016 14:48:24 GMT

and as you mentioned GRE over ipsec I've set up a lab with the below, still no joy, if that worked I would just import static route into ospf area 0, the option below has been tried with g1/0/25 in route mode and then that was used as a source for both tunnels, still no joy

SWITCH A

#
service-loopback group 1 type tunnel
#
vlan 40
desc LINK FROM A TO B
#
vlan 10
description LAN_A
#
int vlan 10
ip add 10.10.10.1 24
desc LAN_A
#
int vlan 40
ip add 10.40.40.1 24
desc LINK FROM A TO B
ipsec policy test
#
int g1/0/25
port link-mode bridge
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 40 unt
port hybrid pvid vlan 40
#
int e1/0/1
port link-mode bridge
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 10 untagged
port hybrid pvid vlan 10
#
int e1/0/2
undo stp
port service-loopback group 1
#
acl number 3030
rule 0 permit ip source 10.40.40.1 0 dest 10.40.40.2 0
#
ike peer test
pre-shared-key simple Password_1
remote-address 10.40.40.2
local-address 10.40.40.1
#
ipsec policy test 1 isakmp
security acl 3030
ike-peer test
proposal tran1
#
ipsec proposal tran1
esp authentication-algorithm sha1
esp encryption-algorithm aes 256
#
int tun1
ip add 1.1.1.1 24
source vlan-interface 40
destination 10.40.40.2
service-loopback-group 1
#
ip route-static 10.20.20.0 24 Tunnel 1

###################################################

SWITCH B
#
service-loopback group 1 type tunnel
#
vlan 40
desc LINK FROM A TO B
#
vlan 10
description LAN_A
#
int vlan 20
ip add 10.20.20.1 24
desc LAN__B
#
int vlan 40
ip add 10.40.40.2 24
desc LINK FROM B TO A
ipsec policy test
#
int g1/0/25
port link-mode bridge
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 40 unt
port hybrid pvid vlan 40
#
int e1/0/1
port link-mode bridge
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 20 untagged
port hybrid pvid vlan 20
#
int e1/0/2
undo stp
port service-loopback group 1
#
acl number 3030
rule 0 permit ip source 10.40.40.2 0 dest 10.40.40.1 0
#
ike peer test
pre-shared-key simple Password_1
remote-address 10.40.40.1
local-address 10.40.40.2
#
ipsec policy test 1 isakmp
security acl 3030
ike-peer test
proposal tran1
#
ipsec proposal tran1
esp authentication-algorithm sha1
esp encryption-algorithm aes 256
#
int tun1
ip add 1.1.1.2 24
source vlan-interface 40
destination 10.40.40.1
service-loopback-group 1
#
ip route-static 0.0.0.0 0 Tunnel 1

Re: IPsec problem

user115 — Mon, 08 Aug 2016 14:26:41 GMT

Ok, now i guess i have got it - you won't the whole traffic exiting your vlan 10 to be encrypted between HP3600B and HP3600A. Configs look quite good, still I don't like the "any" in encryption ACL for the pure IPSEC case, and "rule 0 permit ip" instead of "rule 0 permit gre" in the second case. Sadly, I haven't got Comware 5 to test right now, but here is my gre over ipsec config for comware 7:

acl advanced 3300
rule 10 permit gre source 1.1.1.1 0 destination 2.2.2.2 0

ipsec transform-set TR-DEFAULT
esp encryption-algorithm aes-cbc-128
esp authentication-algorithm sha1
#
ipsec policy map 10 isakmp
transform-set TR-DEFAULT
security acl 3300
local-address 1.1.1.1
remote-address 2.2.2.2
ike-profile IPSecProf

ike proposal 10
encryption-algorithm aes-cbc-128
dh group2

ike profile IPSecProf
keychain 10
match remote identity address 2.2.2.2 255.255.255.255

ike keychain 10
pre-shared-key address 2.2.2.2 255.255.255.255 key cipher <key>

interface Tunnel0 mode gre
ip address 192.168.255.1 255.255.255.252
tcp mss 1340
ip mtu 1380
source 1.1.1.1
destination 2.2.2.2

Then you just enable your ospf for your tunnel network and disable for the vlan. So the traffic which is routed through the switch would be encrypted.

Also, look if the IKE SA and IPSEC SA are established. Try performing debug if no, I guess you might not get you IPSEC SA up with such proposals.

Re: IPsec problem

pattap — Fri, 12 Aug 2016 10:47:33 GMT

how about your ACL:

acl advanced 3300
rule 10 permit gre source 1.1.1.1 0 destination 2.2.2.2 0

I udnerstand that you have used ip addresses of the int vlan that you've used for sourece/destination of your tunnel.

I thought that acl should be allowing tunnel ip addresses, so in your case that would be rule 10 permit gre source 192.168.255.1 0 dest 192.168.255.2 0 and of course mirrored acl at the other end?

And bear in mind that I'm trying to set up GRE over IPsec not other way around

Re: IPsec problem

user115 — Tue, 16 Aug 2016 13:06:50 GMT

Yes, you've understood correctly. That's the way it should be because you need to encrypt GRE traffic between two endpoints. It means that you encrypt the gre traffic between 1.1.1.1 and 2.2.2.2 (so, once again - encrypt GRE tunnel itself) and the traffic inside the gre tunnel will flow encrypted. Practically, the GRE tunnel itself gets encrypted.

If you set up your acl as you have written, you'll get IPSEC over GRE, because the tunnel itself will set up between 1.1.1.1 and 2.2.2.2, tunnel IPs would be visible in cleartext, only data between tunnel IPs would be encrypted. Also if you do it this way another problem would be introduced - that you won't be able to write the correct ACL - what do I mean - when you encrypt traffic between tunnel addresses you should state ACL once again which traffic should be encrypted (e.g. your two subnets) - but you need all of your traffic encrypted - and it won't be so easy. Your ACL would encrypt only traffic with source 192.168.255.1 and destination 192.168.255.2. Traffic from your subnet (don't remember it) e.g. 10.10.10.0/24 to 10.20.20.0/24 will still need an ACL to get encrypted inside GRE and not to flow unencrypted over it.

If you do GRE over IPSEC (as in my case) tunnel becomes encrypted and can easily forward simple routed traffic as well as OSPF Hellos and so on - so all traffic whch would flow through the tunnel (it's ospf's work to do so) will get encrypted as you need.

Re: IPsec problem

pattap — Fri, 02 Sep 2016 08:31:36 GMT

regardless of what we try I don't think this can be done on 3600 switches.

I found the below in security guide for 3600:

“ACL-based IPsec can protect only traffic that is generated by the device and traffic that is destined for the

device. You cannot use an ACL-based IPsec tunnel to protect user traffic.”

http://h10032.www1.hp.com/ctg/Manual/c04074911

ref: page 268

I am now wondering why to even bother with making IPSEC available if it can only be used for traffic generated by the switch - to encrypt your logs and/or protocol talk between the two?!

Re: IPsec problem

user115 — Wed, 07 Sep 2016 08:18:39 GMT

Well, in fact the GRE traffic will be generated by the switch itself - so you could try. User data will be just packed in the GRE packets genereated by the switch.

But, yes, it's better to use routers for VPN, imho.

Re: IPsec problem

pattap — Mon, 12 Sep 2016 07:52:31 GMT

I've tried it. I have strange feeling that with GRE it might be the same as with ipsec - only for traffic generated by the switches.

Now why I think that. When pinging and RDPing from machine on LANA to machine on LANB, so user traffic, I can't see statistics on tunnel interface being populated at all...but when pinging from switchA to switchB statistics on the tunnel increase.

I haven't found anything on that in guides for 3600 so far

Re: IPsec problem

user115 — Thu, 22 Sep 2016 12:47:17 GMT

So, did i get you right - host form LAN-A can ping host in LAN-B, but the statistics on the tunnel doesn't increase? Do you have the route pointing on switch A to LAN B on your tunnel interface or physical one?

Re: IPsec problem

Pete W — Tue, 26 Nov 2019 09:50:08 GMT

Did you ever get this IPsec tunnel to come up.

I'm in a similar position, as I need IPsec between 2 x 5510HI switches and I'm seeing the following text in the configuraton guide:

"ACLs for IPsec take effect only on traffic that is generated by the device and traffic that is destined for
the device."

Regards,

Pete