date:20161106

Re: [strongSwan] Why doesn't table 220 change forwarded packets source IP address?

2016-11-06 Thread Richard Chan

My scenario is  VMs behind the roadwarrior(carol) reaching gateway(moon)'s
subnets (alice).

1. carol to moon subnets - this works correctly as a point2site network.

2. carol - has a KVM libvirt 192.168.122.0/24  network totally unknown to
moon. I want these VMs to reach the subnets behind moon by carol being a
VPN/NAT. To my surprise:

a. this works by SNAT of 192.168.122.x in POSTROUTING to carol's leftip

b. why is this surprising: I thought table 220 would intercept these
packets as well ("from all"), change the source to leftip, no connection
tracking,  and therefore the return packets would fail.

However, what happened was that packets from 192.168.122.0/24 to moon,
skipped table 220, giving me a chance to SNAT in POSTROUTING and it works!

3. Now ip rule 220 looks like a "from all" rule so I'm  curious why didn't
 forwarded packets from carol libvirt 192.168.122.0/24 didn't get affected
by the policy.

I.e.

192.168.122.2 (VM) --- carol(roadwarrior, leftip=10.1.1.1) 
moon(gateway) --- alice 10.1.2.1

* carol can reach alice
* moon: does not know about 192.168.122.0/24

Expected: 192.168.122.2 to 10.1.2.1 to fail because 192.168.122.0/24 would
be "ip rule 220"-ed and changed to 10.1.1.1, and carol has no connection
tracking for this packet.

Observed:  192.168.122.x to 10.1.2.1, skips table 220, reaches POSTROUTING,
and can be SNAT
 to 10.1.1.1 (and everything works).

Sorry, if I was not clear earlier. I meant, I didn't expect subnets behind
the roadwarrior to be able to make it moon.

On Sun, Nov 6, 2016 at 10:10 PM, Andreas Steffen <
andreas.stef...@strongswan.org> wrote:

> Hi Richard,
>
> the table 220 source IP routing rule applies to packets originating
> from the VPN gateway itself, only . If you want roadwarriors from a
> subnet behind the GW to assume this address then you have to NAT them
> to the GW's address. Since the table 220 rule usually maps the GW's
> source address to the local interface on the subnet I don't see
> the sense of the roadwarriors belonging to this subnet to assume
> the gateway's internal address.
>
> Regards
>
> Andreas
>
> On 05.11.2016 18:01, Richard Chan wrote:
>
>> Hi, in the roadwarrior configuration, from a conceptual point of view,
>> why doesn't table 220 change the source IP address of forwarded packets
>> (say the roadwarrior has a subnet behind it)?
>>
>> # ip ro sho table 220
>> 10.0.0.0/8  via 192.168.1.1 dev eth0  proto static
>>   src 10.2.0.3
>>
>> # ip rule show
>> 0:  from all lookup local
>> 220:from all lookup 220
>> 32766:  from all lookup main
>> 32767:  from all lookup default
>>
>> roadwarrior has a separate subnet 192.168.2.0/24 
>> and is forwarding/NAT'ing packets.  When  I ping a host on the central
>> site LAN
>>
>> - OUTPUT chain sees the source IP address as 10.2.0.3 (table 220 is
>> working!)
>> -  FORWARD chain sees the source IP address as 192.168.2.X  (host cannot
>> be reached until these packets are SNAT'ed to 10.2.0.3)
>>
>>
> Richard Chan
>>
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Open Source VPN Solution!  www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[ITA-HSR]==
>
>

-- 
Richard Chan
Chief Architect

TreeBox Solutions Pte Ltd
1 Commonwealth Lane #03-01
Singapore 149544
Tel: 6570 3725
http://www.treeboxsolutions.com

Co.Reg.No. 201100585R
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] ikev2 server without cert

2016-11-06 Thread Derek Cameron

Yes, you can use username and password. In this tutorial, the
strongSwan server authenticates with a certificate, and the various
clients authenticate with a user name and password:

http://xpu.ca/strongswan-ubuntu/

This procedure was tested on an Amazon EC2 t2.micro instance running
Ubuntu 16.04. The version of the strongSwan package installed was
5.3.5-1ubuntu3.

On Sun, Nov 6, 2016 at 3:11 PM, robert k Wild  wrote:
> hi all,
>
> im trying to create an ikev2 server but this how-to guide says i need to
> create certs for the server and client, can i just not use normal username
> and password for authentication?
>
> https://raymii.org/s/tutorials/IPSEC_vpn_with_CentOS_7.html
>
> many thanks,
>
> rob
>
> --
> Regards,
>
> Robert K Wild.
>
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] ikev2 server without cert

2016-11-06 Thread robert k Wild

hi all,

im trying to create an ikev2 server but this how-to guide says i need to
create certs for the server and client, can i just not use normal username
and password for authentication?

https://raymii.org/s/tutorials/IPSEC_vpn_with_CentOS_7.html

many thanks,
rob

-- 
Regards,

Robert K Wild.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] AH Transport AES-128 GMAC

2016-11-06 Thread Gyula Kovács


Hello,

I'm trying to set up an ikev2/host2host-ah connection according to 
https://www.strongswan.org/testing/testresults/ikev2/host2host-ah/index.html 
page.
The connection is successfully established when I'm using the aesxcbc 
integrity algorithm (as in the example).
See ipsec_listalgs__2.txt, ipsec_status__2.txt and 
ipsec_up_host-host_transport_ah_aesxcbc__2.txt files.


But, according to our customer's requirements, I have to use aes128gmac 
integrity algorithm.

So I changed the "ah=aesxcbc" to "ah=aes128gmac" in the ipsec.conf file.
The connection could not be established with the new setting (see 
ipsec_up_host-host_transport_ah_aes128gmac__2.txt file).


My test environment (both hosts):
- Debian 8.6 VM
- StongSwan 5.5.1 (built as Debian has StrongSwan 5.2.1 by default)

Anybody have an idea what could be wrong?

Best regards,
Gyula Kovacs

root@atm:/etc/ipsec.d/examples# ipsec listalgs

List of registered IKE algorithms:

  encryption: AES_CBC[aes] 3DES_CBC[des] DES_CBC[des] DES_ECB[des] RC2_CBC[rc2] 
CAMELLIA_CBC[openssl] CAST_CBC[openssl]
  BLOWFISH_CBC[openssl] NULL[openssl]
  integrity:  HMAC_MD5_96[openssl] HMAC_MD5_128[openssl] HMAC_SHA1_96[openssl] 
HMAC_SHA1_128[openssl]
  HMAC_SHA1_160[openssl] HMAC_SHA2_256_128[openssl] 
HMAC_SHA2_256_256[openssl] HMAC_SHA2_384_192[openssl]
  HMAC_SHA2_384_384[openssl] HMAC_SHA2_512_256[openssl] 
HMAC_SHA2_512_512[openssl] CAMELLIA_XCBC_96[xcbc]
  AES_XCBC_96[xcbc] AES_CMAC_96[cmac]
  aead:   AES_GCM_16[openssl] AES_GCM_12[openssl] AES_GCM_8[openssl]
  hasher: HASH_SHA1[sha1] HASH_SHA224[sha2] HASH_SHA256[sha2] 
HASH_SHA384[sha2] HASH_SHA512[sha2] HASH_MD5[md5]
  HASH_MD4[openssl]
  prf:PRF_KEYED_SHA1[sha1] PRF_HMAC_MD5[openssl] PRF_HMAC_SHA1[openssl] 
PRF_HMAC_SHA2_256[openssl]
  PRF_HMAC_SHA2_384[openssl] PRF_HMAC_SHA2_512[openssl] 
PRF_FIPS_SHA1_160[fips-prf] PRF_AES128_XCBC[xcbc]
  PRF_CAMELLIA128_XCBC[xcbc] PRF_AES128_CMAC[cmac]
  xof:
  dh-group:   ECP_256[openssl] ECP_384[openssl] ECP_521[openssl] 
ECP_224[openssl] ECP_192[openssl] ECP_256_BP[openssl]
  ECP_384_BP[openssl] ECP_512_BP[openssl] ECP_224_BP[openssl] 
MODP_3072[openssl] MODP_4096[openssl]
  MODP_6144[openssl] MODP_8192[openssl] MODP_2048[openssl] 
MODP_2048_224[openssl] MODP_2048_256[openssl]
  MODP_1536[openssl] MODP_1024[openssl] MODP_1024_160[openssl] 
MODP_768[openssl] MODP_CUSTOM[openssl]
  random-gen: RNG_WEAK[openssl] RNG_STRONG[random] RNG_TRUE[random]
  nonce-gen:  [nonce]
root@atm:/etc/ipsec.d/examples#
root@atm:/etc/ipsec.d/examples# ipsec status
Security Associations (1 up, 0 connecting):
   host-host[1]: ESTABLISHED 91 seconds ago, 
192.168.1.211[!DELETED-BECAUSE-OF-CONFIDENTIALITY!]...192.168.1.212[!DELETED-BECAUSE-OF-CONFIDENTIALITY!]
   host-host{1}:  INSTALLED, TRANSPORT, reqid 1, AH SPIs: c621bb4b_i c47a8f2e_o
   host-host{1}:   192.168.1.211/32 === 192.168.1.212/32
root@atm:/etc/ipsec.d/examples#
root@atm:/etc/ipsec.d/examples# ipsec up host-host
initiating IKE_SA host-host[1] to 192.168.1.212
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.1.211[500] to 192.168.1.212[500] (1156 bytes)
received packet: from 192.168.1.212[500] to 192.168.1.211[500] (657 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ 
N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
received cert request for "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
received cert request for "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
received cert request for "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
sending cert request for "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
sending cert request for "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
sending cert request for "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
authentication of '!DELETED-BECAUSE-OF-CONFIDENTIALITY!' (myself) with 
RSA_EMSA_PKCS1_SHA2_256 successful
sending end entity cert "!DELETED-BECAUSE-OF-CONFIDENTIALITY!"
establishing CHILD_SA host-host
generating IKE_AUTH request 1 [ IDi CERT CERTREQ AUTH N(USE_TRANSP) SA TSi TSr 
N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
splitting IKE message with length of 1920 bytes into 2 fragments
generating IKE_AUTH request 1 [ EF(1/2) ]
generating IKE_AUTH request 1 [ EF(2/2) ]
sending packet: from 192.168.1.211[4500] to 192.168.1.212[4500] (1236 bytes)
sending packet: from 192.168.1.211[4500] to 192.168.1.212[4500] (756 bytes)
received packet: from 192.168.1.212[4500] to 192.168.1.211[4500] (1236 bytes)
parsed IKE_AUTH response 1 [ EF(1/2) ]
received fragment #1 of 2, waiting for complete IKE message
received packet: from 192.168.1.212[4500] to 192.168.1.211[4500] (548 bytes)
parsed IKE_AUTH response 1 [ EF(2/2) ]
received fragment #2 of 2, reassembling fragmented IKE message
parsed IKE_AUTH response 1 [ IDr CERT AUTH N(AUTH_LFT) N(MOBIKE_SUP) 
N(NO_ADD_ADDR) N(NO_PROP) ]
received end

Re: [strongSwan] Why doesn't table 220 change forwarded packets source IP address?

2016-11-06 Thread Andreas Steffen


Hi Richard,

the table 220 source IP routing rule applies to packets originating
from the VPN gateway itself, only . If you want roadwarriors from a
subnet behind the GW to assume this address then you have to NAT them
to the GW's address. Since the table 220 rule usually maps the GW's
source address to the local interface on the subnet I don't see
the sense of the roadwarriors belonging to this subnet to assume
the gateway's internal address.

Regards

Andreas

On 05.11.2016 18:01, Richard Chan wrote:

Hi, in the roadwarrior configuration, from a conceptual point of view,
why doesn't table 220 change the source IP address of forwarded packets
(say the roadwarrior has a subnet behind it)?

# ip ro sho table 220
10.0.0.0/8  via 192.168.1.1 dev eth0  proto static
  src 10.2.0.3

# ip rule show
0:  from all lookup local
220:from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

roadwarrior has a separate subnet 192.168.2.0/24 
and is forwarding/NAT'ing packets.  When  I ping a host on the central
site LAN

- OUTPUT chain sees the source IP address as 10.2.0.3 (table 220 is
working!)
-  FORWARD chain sees the source IP address as 192.168.2.X  (host cannot
be reached until these packets are SNAT'ed to 10.2.0.3)




Richard Chan

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Why doesn't table 220 change forwarded packets source IP address?

Re: [strongSwan] ikev2 server without cert

[strongSwan] ikev2 server without cert

[strongSwan] AH Transport AES-128 GMAC

Re: [strongSwan] Why doesn't table 220 change forwarded packets source IP address?

5 matches

Site Navigation

Mail list logo

Footer information