Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 2219 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.
  • 0
    Manuel, I hope you keep it and keep asking (and answering!) good questions!

    I hadn't considered whether it was possible to have a user use different access rules based on policy, rather than a different username for each policy.  Do you have the 'Strict policy' box checked in each of the two policies?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob

    Thanks for your input!
    I hadn't considered whether it was possible to have a user use different access rules based on policy, rather than a different username for each policy.

    Well, but you have to agree that in my scenario it is fair to say that a multi-policy distinction makes more sense than one based on the user. After all, it's the same person connecting to the unit, so let him use his one and only username ;-).

    Do you have the 'Strict policy' box checked in each of the two policies?

    To be honest: I guess. But would that make much of a difference considering the mode_cfg behavior?
    Sidenote: Right now, I'm packing my bags because I'll be on vacation until july 14th. No network lab, no bugs, just me (thinking about the network lab and bugs *smirk*). When I'm back, I'll let you know subito.

    I hope you keep it

    Yes, we decided to. Let's hope for the best...

    Cheers and have a nice week,
    Manuel
  • 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
  • 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
  • 0
    If you got the evaluation unit through a reseller, you can let them know and they can pass the information along to Astaro.  If you got the eval unit from Astaro sales, get in touch with your sales contact.
  • 0 in reply to Scott_Klassen
    Hi Scott

    If you got the evaluation unit through a reseller, you can let them know and they can pass the information along to Astaro.  If you got the eval unit from Astaro sales, get in touch with your sales contact.

    Well, they are no longer evaluation units since we purchased them before my vacation (see post above).
    I now contacted our local reseller and will let you know about future developments asap.

    Cheers and good night,
    Manuel
  • 0
    Hi guys

    It turns out that the VPN server does not know about the destination network at the time it allocates an IP out of the VPN pool (this happens during main mode). Therefore, the server can't decide, which VPN policy the client intended to use and as a result randomly assigns IPs.
    The workaround for the time being would be: Create one large VPN pool and define several firewall rules based on UserGroup objects. This way, it is at least possible to maintain a certain order.

    When I have some time to spare, I will further investigate this issue and try to find a solution. Of course, with IPv6, one would just assign each client an external IP for his policy to connect to - problem solved. But with the scarcity of IPv4 addresses I don't dare to do so right now.

    Cheers,
    Manuel