Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 2220 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN pool bug (or feature?)

gartoffel
Well, it's me again, hi guys!

I promise, I won't bother you anymore (or at least not that much) once the evaluation of the units is done, but right now I need to know whether the following behavior is a bug or a feature:

I added two VPN IPSec connections. They are quite simple:

  • COMPANY1: Policy states, that they can connect to external IP A using X.509 as authentication method, XAUTH is enabled. They should get an IP out of POOL_COMPANY1 (10.5.111.0/24) and then be able to connect to VLAN1 (10.5.110.0/24).
  • COMPANY2: Policy states, that they can connect to the same external IP A using X.509 as authentication method, XAUTH is also enabled. They on the other hand should get an IP out of POOL_COMPANY2 (10.5.121.0/24) and then connect to a VLAN2 (10.5.120.0/24).

So far so good, everything works great (StrongSwan's doing a great job here *wink*).

Scenario
Let's say I have a user "support". He helps COMPANY1 and COMPANY2 maintain their servers. So he set up two policies on his computer - one to be able to connect to remote VLAN1 and one to remote VLAN2.

Expected result
What I expected to happen was that this user "support" gets an IP out of POOL_COMPANY1 when connecting using the policy of COMPANY1. And that he gets another IP out of POOL_COMPANY2 when connecting using the policy of COMPANY2.

Actual result
What I get is this: No matter with what policy I connect, I always get the same IP out of POOL_COMPANY1. It's like Astaro is caching my VPN mode_cfg answer which is really annoying in my case.

Bug or a feature, that is the question?

Cheers and thanks,
Manuel


This thread was automatically locked due to age.
Parents
  • 0
    Have a great vacation, Manuel!

    The default with the pre-configured policies is with 'Strict policy' unchecked.  That lets people connect even if their local policy doesn't match up perfectly.

    Still, I suspect that he'll either login or be rejected by the first access rule, and he'll not get an opportunity for the second.  But, I don't know that, so I'm glad you're testing it!

    Cheers - Bob (whose vacation is at the end of August [;)])
  • 0 in reply to BAlfson
    Hi Bob

    Have a great vacation, Manuel!

    Thanks, it was great. And no emergency calls or desperate mails either. Hope, you'll be able to enjoy yours as much as I was...

    Back to business:

    • I tried using 'strict policy', no change.
    • I tried without 'strict policy', no change.
    • I tried giving both Companies the same Policy, no change.
    • I tried giving both Companies different Policies, no change.

    Bottom line: I always get the same @#$ IP from the pool I first connected to. If I wait long enough (like half an hour, i didn't check my watch), the ASG forgets the IP I last got and gives me a correct new one. This lease-timer is very good, but please not policy spanning!

    Here are some logs to understand what happens.

    Connecting to COMPANY1 
    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: parsing ModeCfg request

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: peer requested virtual IP %any

    2011:07:15-16:17:48 vpn-1 pluto[7199]: acquired existing lease for address 10.5.111.1 in pool 'NET_COMPANY1_VPN'

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: sending ModeCfg reply

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: sent ModeCfg reply, established

    2011:07:15-16:17:50 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #16: responding to Quick Mode

    2011:07:15-16:17:50 vpn-1 pluto[7199]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="support" variant="ipsec" srcip="192.168.1.10" virtual_ip="10.5.111.1"

    2011:07:15-16:17:50 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #16: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:17:50 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #16: IPsec SA established {ESP=>0x00a6b3b9 


    Reconnecting to COMPANY1 
    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: parsing ModeCfg request

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: peer requested virtual IP %any

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: sending ModeCfg reply

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: sent ModeCfg reply, established

    2011:07:15-16:18:58 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #18: responding to Quick Mode

    2011:07:15-16:18:58 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #18: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:18:58 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #18: IPsec SA established {ESP=>0x0f852e97 


    Connecting to COMPANY2 (this is, where the buggy behavior starts! It doesn't even realize, that I am connecting to COMPANY2 at first.) 
    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: parsing ModeCfg request

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: peer requested virtual IP %any

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: sending ModeCfg reply

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: sent ModeCfg reply, established

    2011:07:15-16:19:53 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #22: responding to Quick Mode

    2011:07:15-16:19:53 vpn-1 pluto[7199]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="support" variant="ipsec" srcip="192.168.1.10" virtual_ip="10.5.111.1"

    2011:07:15-16:19:54 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #22: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:19:54 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #22: IPsec SA established {ESP=>0x069c7a75 


    Reconnecting to COMPANY2 (it now realizes, that I want to connect to COMPANY2, but still giving me the wrong IP address) 
    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: parsing ModeCfg request

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: peer requested virtual IP %any

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: sending ModeCfg reply

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: sent ModeCfg reply, established

    2011:07:15-16:20:37 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #24: responding to Quick Mode

    2011:07:15-16:20:37 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #24: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:20:37 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #24: IPsec SA established {ESP=>0x0f381e1c 


    Still, I suspect that he'll either login or be rejected by the first access rule, and he'll not get an opportunity for the second.

    No, I can still connect. So using strict or not doesn't influence the ability to connect (and this behavior is correct, because strict only checks for differences between client and server policy - which does not include the client IP).

    So I hereby officially declare this as a bug, which needs to be addressed. Where can I file a bug report?

    Cheers,
    Manuel
Reply
  • 0 in reply to BAlfson
    Hi Bob

    Have a great vacation, Manuel!

    Thanks, it was great. And no emergency calls or desperate mails either. Hope, you'll be able to enjoy yours as much as I was...

    Back to business:

    • I tried using 'strict policy', no change.
    • I tried without 'strict policy', no change.
    • I tried giving both Companies the same Policy, no change.
    • I tried giving both Companies different Policies, no change.

    Bottom line: I always get the same @#$ IP from the pool I first connected to. If I wait long enough (like half an hour, i didn't check my watch), the ASG forgets the IP I last got and gives me a correct new one. This lease-timer is very good, but please not policy spanning!

    Here are some logs to understand what happens.

    Connecting to COMPANY1 
    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: parsing ModeCfg request

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: peer requested virtual IP %any

    2011:07:15-16:17:48 vpn-1 pluto[7199]: acquired existing lease for address 10.5.111.1 in pool 'NET_COMPANY1_VPN'

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: sending ModeCfg reply

    2011:07:15-16:17:48 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #15: sent ModeCfg reply, established

    2011:07:15-16:17:50 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #16: responding to Quick Mode

    2011:07:15-16:17:50 vpn-1 pluto[7199]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="support" variant="ipsec" srcip="192.168.1.10" virtual_ip="10.5.111.1"

    2011:07:15-16:17:50 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #16: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:17:50 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #16: IPsec SA established {ESP=>0x00a6b3b9 


    Reconnecting to COMPANY1 
    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: parsing ModeCfg request

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: peer requested virtual IP %any

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: sending ModeCfg reply

    2011:07:15-16:18:56 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #17: sent ModeCfg reply, established

    2011:07:15-16:18:58 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #18: responding to Quick Mode

    2011:07:15-16:18:58 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #18: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:18:58 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #18: IPsec SA established {ESP=>0x0f852e97 


    Connecting to COMPANY2 (this is, where the buggy behavior starts! It doesn't even realize, that I am connecting to COMPANY2 at first.) 
    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: parsing ModeCfg request

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: peer requested virtual IP %any

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: sending ModeCfg reply

    2011:07:15-16:19:52 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY1"[3] 192.168.1.10 #21: sent ModeCfg reply, established

    2011:07:15-16:19:53 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #22: responding to Quick Mode

    2011:07:15-16:19:53 vpn-1 pluto[7199]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="support" variant="ipsec" srcip="192.168.1.10" virtual_ip="10.5.111.1"

    2011:07:15-16:19:54 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #22: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:19:54 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #22: IPsec SA established {ESP=>0x069c7a75 


    Reconnecting to COMPANY2 (it now realizes, that I want to connect to COMPANY2, but still giving me the wrong IP address) 
    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: parsing ModeCfg request

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: peer requested virtual IP %any

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: assigning virtual IP 10.5.111.1 to peer

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: sending ModeCfg reply

    2011:07:15-16:20:36 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #23: sent ModeCfg reply, established

    2011:07:15-16:20:37 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #24: responding to Quick Mode

    2011:07:15-16:20:37 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #24: Dead Peer Detection (RFC 3706) enabled

    2011:07:15-16:20:37 vpn-1 pluto[7199]: "D_SoftVPN_COMPANY2"[1] 192.168.1.10 #24: IPsec SA established {ESP=>0x0f381e1c 


    Still, I suspect that he'll either login or be rejected by the first access rule, and he'll not get an opportunity for the second.

    No, I can still connect. So using strict or not doesn't influence the ability to connect (and this behavior is correct, because strict only checks for differences between client and server policy - which does not include the client IP).

    So I hereby officially declare this as a bug, which needs to be addressed. Where can I file a bug report?

    Cheers,
    Manuel
Children
  • 0 in reply to gartoffel
    I always get the same @#$ IP from the pool I first connected to. If I wait long enough (like half an hour, i didn't check my watch), the ASG forgets the IP I last got and gives me a correct new one.

    After further testing, I am forced to correct the above statement:
    It's true, I always get the same IP out of the same pool - this is either an error by design or a bug. But there is no lease time and the ASG doesn't seem to forget, what IP I got.

    So, what should I do now? Who do I need to address with this issue?

    Cheers,
    Manuel