Noel, thanks for your help. I was able to get it working with the passthrough option. I hadn’t really come across any examples using it so I didn’t think to use it. I still encountered some odd behavior getting it to work but by making sure I put it right after my ‘toserver’ stanza it seems to work. Thanks again,
-David Mitchell On Jan 10, 2015, at 6:37 PM, Noel Kuntze <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello David, > > You have fallen for a misconception. > The leftsubnet parameter controls what source addresses in an IP packet are > valid for tunneling. > The rightsubnet parameter controls what destination addresses in an IP packet > are valid for tunneling. > Those two constraints are used to find out what packets should go through the > tunnel by checking > the source and destination and seeing if both match. > > So your configuration tells your client to tunnel any packets whose source is > in the subnet 192.168.1.0/24 > and the destination is in the subnet 0.0.0.0/0 (any IP address). > > What you want is a passthrough policy with source and destination being > 192.168.1.0/24. > That policy with narrower subnets will take precedence before the policy that > is defined by > your "toclient" connection definition. > > conn lanbypass > leftsubnet=192.168.1.0/24 > rightsubnet=192.168.1.0/24 > type=passthrough > auto=route > > Split tunneling does not involve "lefthostaccess" or any other such things. > Split tunneling can be done by two things: > *Defining your leftsubnet and rightsubnet definitions so they do not cover > the subnet you want to exclude. > *Push or locally define such passthrough policies. (Can be done using the > attr or attr-sql plugin) > > > Mit freundlichen Grüßen/Regards, > Noel Kuntze > > GPG Key ID: 0x63EC6658 > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > > Am 11.01.2015 um 01:24 schrieb David Mitchell: >> Greetings, >> >> I’m trying to set up what should be a simple split tunnel configuration and >> am having issues. The client is on a NAT subnet so I have >> leftsubnet=192.168.1.0/24. I want everything except traffic for the LAN to >> go out the IPsec tunnel so I have rightsubnet=0.0.0.0/0. The tunnel comes up >> fine but _all_ traffic goes out the tunnel, even traffic destined for >> 192.168.1.0/24. If I try to ping some other host on the local subnet I can >> see the ICMP request on the VPN server where it shouldn’t be. The VPN server >> can (as expected) send an ICMP to a host on the LAN. I’ve tried both with >> and without lefthostaccess=yes (which I though would basically control split >> tunneling). >> >> Both servers are Debian Wheezy using the Strongswan 4.X packages. I can try >> the Strongswan 5.X packages from back ports but my impression is that this >> should work just fine. It’s not a complex configuration so I’m kind of >> stumped as to why it’s not working. I’m thinking that if I use ‘setkey -DP’ >> on the client I should see a rule matching 192.168.1.0/24 - 192.168.1.0/24 >> to keep the local traffic out of the tunnel? Or is there some other method I >> should be checking? Any advice would be appreciated. Thanks, >> >> -David Mitchell >> >> On the server: >> conn toclient >> keyexchange=ikev2 >> left=1.1.1.1 >> leftid=1.1.1.1 >> leftcert=serverCert.der >> leftsubnet=0.0.0.0/0 >> rightcert=clientCert.pem >> right=%any >> # righthostaccess=yes >> rightsubnet=192.168.1.0/24 >> auto=add >> >> On the client: >> conn toserver >> keyexchange=ikev2 >> right=1.1.1.1 >> rightcert=serverCert.der >> rightsubnet=0.0.0.0/0 >> leftsubnet=192.168.1.0/24 >> leftcert=clientCert.pem >> # lefthostaccess=yes >> auto=add >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.strongswan.org/mailman/listinfo/users > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJUsdPOAAoJEDg5KY9j7GZYX4QP/1HX7nLThrmjYP3+H4A6xhQY > 3RMQ7fMoeYcqjFNNBtohaOD3sCKlhPuhc1kmQfPTUGJw2FwjmPVzLlnkL90Iyj+o > hmSjx9C0wrkRF4HUL+7gIgJ8o7VcXltmDVgrl8vJL1REkTUM9F7FPk+JSm5oUVbX > rk7TUkIr5X3nhYyqEdvL4Xy5hWyBNfBMbhAdFrcz7T/0eqESDSMbviDxYWKbuTrF > cMUNSuW9r7bXsWNg4JMKFvKFVQF6jaTaHzqTRjvAsKVAjz6jFnfJWWDOPbEceF/T > IN5+/0YbxxEx8G03MmHaXIzEreFhoCwRHMGvqVMQ+iDgjZzsTG6DjAM+nABAl5S+ > 6wugUwqeEM/xoHqFA00LNzj/5FDpXZg0QRYWKuJERGdi8RytJQYGSp0GyT0FI1/Q > ezuzQJ9njk/FKOeJ0nfY/0C2WmNz/mt1p1XDPFuD6t5/+NFdwqjWpbDwqj3zaG3i > KY5FEZfAXLlfKigQyUBGDOtaqcL1C1VRBOqIx+fVxAjrBV7ipL9I6WugFU441jwe > hkyEjDd9zWT7CMRYVYMVJ/UxCedWxpRK0ChdiBOlO8GC1HGKdfabqrOHxVjczyzc > vzqzttxov6lG02xRYE4cicFpb9OvhkVWIGez+j4jYmm3AUhDOJqeSzHNKAzJDfXk > mSEdyt8IR88qRopbJ9yC > =KIXc > -----END PGP SIGNATURE----- > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
