IPsec problem

[pattap]

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?

[user115]

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.

[user115]

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.

[pattap]

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

[pattap]

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

[user115]

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.

[pattap]

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

[user115]

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.

[pattap]

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?!

[user115]

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.