Project

General

Profile

Actions

Bug #1290

closed

IPsec roadwarrior use case: Traffic from LAN does not hit established tunnel

Added by Tero Mononen about 13 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
02/17/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:
amd64

Description

Hello.

Remote Access IPsec client (Shrew) connecting to pfSense firewall terminating the IPsec connection does not work properly. The tunnel setup is fine (e.g. Phase-1, XAuth and Qm are run OK, and the IPsec SA's are established), traffic from client (from-tunnel) is decrypted fine, but traffic from LAN (to-tunnel) does not enter the tunnel. Instead of being properly tunneled, it causes a PFKEY acquire to be generated (which will result into remote access server starting negotiation towards the client - separate issue).

Setup is as follows:

Client is given IP addresses from pool 10.9.1.32/28. The LAN network is 10.9.0.0/32. The server side tunnel endpoint address is
212.16.111.196 and for the client side address is 17.0.0.1 (addresses are fake).

Status->IPsec / Overview tab shows the "tunnel" as yellow - which is correct, as the tunnel won't accept traffic from LAN side. The IPsec log shows the following:

Feb 17 11:04:21 racoon: 2011-02-17 11:04:21: INFO: IPsec-SA established: ESP 212.16.111.196500->17.0.0.1500 spi=212324040(0xca7cec8)
Feb 17 11:04:21 racoon: 2011-02-17 11:04:21: INFO: IPsec-SA established: ESP 212.16.111.196500->17.0.0.1500 spi=59899768(0x391ff78)
Feb 17 11:04:21 racoon: [RoadWarrior P1-tunnel]: ERROR: such policy does not already exist: "10.9.1.33/320 10.9.0.0/240 proto=any dir=in"
Feb 17 11:04:21 racoon: [RoadWarrior P1-tunnel]: ERROR: such policy does not already exist: "10.9.0.0/240 10.9.1.33/320 proto=any dir=out"

There are no earlier errors. Some discussion list postings indicate that the last ERROR lines are to be expected.

Client: Shrew Soft VPNCLIENT v2.1.5 (and 2.2.0)
Version: pfSense 2.0 beta (downloaded on Feb 12th, 2011)
Platform: VirtualBox with PCNet-PCI II adapters Attached on different "softswitches" on both side.

Generated policy is:

[2.0-RC1][]/root(1): setkey -DP
10.9.1.33[any] 10.9.0.0/24[any] 255
in ipsec
esp/tunnel/17.0.0.1-212.16.111.196/unique:1
created: Feb 17 10:49:47 2011 lastused: Feb 17 10:49:47 2011
lifetime: 3600(s) validtime: 0(s)
spid=34 seq=1 pid=18473
refcnt=1
10.9.0.0/24[any] 10.9.1.33[any] 255
out ipsec
esp/tunnel/212.16.111.196-17.0.0.1/unique:1
created: Feb 17 10:49:47 2011 lastused: Feb 17 10:49:47 2011
lifetime: 3600(s) validtime: 0(s)
spid=35 seq=0 pid=18473
refcnt=1

And Security Associations are:

[2.0-RC1][]/root(2): setkey -D
212.16.111.196 17.0.0.1
esp mode=any spi=119860504(0x0724ed18) reqid=1(0x00000001)
E: aes-cbc 6c752214 d71f6775 2b692729 106316c6 935a27b8 437a0163 e83f65a9 192044cb
A: hmac-sha1 5c0b652b 7857a7c5 64921c31 58e3eb08 e9633b22
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Feb 17 10:49:47 2011 current: Feb 17 10:50:00 2011
diff: 13(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=18780 refcnt=1
17.0.0.1 212.16.111.196
esp mode=tunnel spi=13833082(0x00d3137a) reqid=1(0x00000001)
E: aes-cbc 87f22816 8c723db1 ef50c678 b97e37be 7caf881f bf295a4d 05dc8790 4ffdd60f
A: hmac-sha1 f150e7ce 73e8aff9 28d7db18 f7cb1949 454d8e74
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Feb 17 10:49:47 2011 current: Feb 17 10:50:00 2011
diff: 13(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=18780 refcnt=1

Actions #1

Updated by Jim Pingle about 11 years ago

  • Status changed from New to Closed

Sounds like one of the other IPsec mobile bugs that was fixed long ago (check other tickets).

Actions

Also available in: Atom PDF