[strongSwan] what the use (effect) of "righthostaccess=yes"

Rajiv Kulkarni rajivkulkarni69 at gmail.com
Mon Nov 20 17:42:50 CET 2017


Hello Andreas

Thanks for the help..

Yes!!! It works!....I did just as mentioned in the example shown by you....


======================================================================
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc# ipsec statusall
Status of IKE charon daemon (weakSwan 5.5.1, Linux 4.4.0-31-generic, i686):
  uptime: 20 seconds, since Nov 20 22:20:41 2017
  malloc: sbrk 2449408, mmap 0, used 315904, free 2133504
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 4
  loaded plugins: charon ldap aes des blowfish rc2 sha2 sha1 md4 md5 random
nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
dnskey sshkey pem openssl gcrypt fips-prf gmp xcbc cmac hmac ctr ccm gcm
sqlite attr kernel-netlink resolve socket-default forecast farp stroke vici
updown eap-identity eap-sim eap-aka eap-simaka-pseudonym eap-md5 eap-gtc
eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc
xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs dhcp lookip
error-notify unity
Listening IP addresses:
  2.2.2.59
  192.168.110.25
  192.168.24.25
  10.232.90.125
  192.168.33.25
  172.17.1.25
  192.168.25.1
Connections:
       togw1:  2.2.2.59...97.1.1.201  IKEv1, dpddelay=30s
       togw1:   local:  [2.2.2.59] uses pre-shared key authentication
       togw1:   remote: [97.1.1.201] uses pre-shared key authentication
       togw1:   child:  192.168.25.0/24 === 192.168.22.0/24 TUNNEL,
dpdaction=clear
Routed Connections:
       togw1{1}:  ROUTED, TUNNEL, reqid 1
       togw1{1}:   192.168.25.0/24 === 192.168.22.0/24
Security Associations (1 up, 0 connecting):
       togw1[1]: ESTABLISHED 8 seconds ago,
2.2.2.59[2.2.2.59]...97.1.1.201[97.1.1.201]
       togw1[1]: IKEv1 SPIs: 61cc45661e76b9e7_i 9182e288ae7b2058_r*,
pre-shared key reauthentication in 23 hours
       togw1[1]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
       togw1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c4c01d32_i
c25a27dc_o
       togw1{2}:  AES_CBC_128/HMAC_SHA1_96, 168 bytes_i (2 pkts, 7s ago),
168 bytes_o (2 pkts, 7s ago), rekeying in 17 hours
       togw1{2}:   192.168.25.0/24 === 192.168.22.0/24
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc# iptables -nvL
Chain INPUT (policy ACCEPT 116 packets, 19111 bytes)
 pkts bytes target     prot opt in     out     source
destination
    2   168 ACCEPT     all  --  eth0   *       192.168.22.0/24
192.168.25.0/24      policy match dir in pol ipsec reqid 1 proto 50

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  eth0   *       192.168.22.0/24
192.168.25.0/24      policy match dir in pol ipsec reqid 1 proto 50
    0     0 ACCEPT     all  --  *      eth0    192.168.25.0/24
192.168.22.0/24      policy match dir out pol ipsec reqid 1 proto 50

Chain OUTPUT (policy ACCEPT 70 packets, 10236 bytes)
 pkts bytes target     prot opt in     out     source
destination
    2   168 ACCEPT     all  --  *      eth0    192.168.25.0/24
192.168.22.0/24      policy match dir out pol ipsec reqid 1 proto 50
root at lssimgw2:/usr/local/etc#
root at lssimgw2:/usr/local/etc# cat ipsec.conf
# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup
        strictcrlpolicy=no
        charondebug="ike 1,chd 1,knl 1,cfg 1"

conn %default
        ikelifetime=24h
        keylife=18h
        mobike=no
        dpddelay=30s
        dpdtimeout=90s
        dpdaction=clear
        rightfirewall=yes
        righthostaccess=yes

conn togw1
        right=2.2.2.59
        left=97.1.1.201
        leftsubnet=192.168.22.0/24
        rightsubnet=192.168.25.0/24
        leftauth=psk
        rightauth=psk
        type=tunnel
        keyexchange=ikev1
        ike=aes128-sha1-modp1024!
        esp=aes128-sha1!
        auto=route
root at lssimgw2:/usr/local/etc#
=====================================================


Never expected or rather never knew that we could swap the left/right roles
too...Its just what you assign...

Thank you...learnt something worthwhile today

regards
Rajiv




On Mon, Nov 20, 2017 at 8:59 PM, Andreas Steffen <
andreas.steffen at strongswan.org> wrote:

> Hi Rajiv,
>
> if "left" is local and "right" is remote then only
> leftfirewall and lefthostaccess are defined.
>
> rightfirewall and righthostaccess are used when
> "right" is local and "left" is remote as in the
> following scenario where sides are swapped:
>
>
> https://www.strongswan.net/testing/testresults/ikev2/config-
> payload-swapped/
>
> Regards
>
> Andreas
>
> On 20.11.2017 15:15, Rajiv Kulkarni wrote:
>
>> Hi
>>
>> I have a ipsec tunnel deployed/configured as below:
>>
>> PC1----(lan)[GW1](wan)=====IPSEC====(wan)[GW2](lan)---PC2
>>
>> PC1-ipaddr: 192.168.22.x
>> PC2-ipaddr: 192.168.25.x
>>
>> GW1-lan-ipaddr: 192.168.22.1
>> GW2-lan-ipaddr: 192.168.25.1
>>
>>
>> I see that to allow access to 192.168.22.1 from PC2 (via the ipsec
>> tunnel) i should use the options "lefthostaccess=yes" (and also
>> leftfirewall=yes)  on GW1
>>
>> And when we use the options..we have the following iptable rules added
>> on GW1 (thru the updown script automatically whenever the tunnel is UP)
>>
>> ------------------------------------------------------------
>> ---------------------------------------
>> root at lssimgw1:/usr/local/etc# iptables -nvL
>> Chain INPUT (policy ACCEPT 52 packets, 4680 bytes)
>>   pkts bytes target     prot opt in     out     source
>> destination
>>      0     0 ACCEPT     all  --  eth0   * 192.168.22.0/24
>> <http://192.168.22.0/24> 192.168.25.0/24 <http://192.168.25.0/24>
>> policy match dir in pol ipsec reqid 1 proto 50
>>
>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>   pkts bytes target     prot opt in     out     source
>> destination
>>      0     0 ACCEPT     all  --  eth0   * 192.168.22.0/24
>> <http://192.168.22.0/24> 192.168.25.0/24 <http://192.168.25.0/24>
>> policy match dir in pol ipsec reqid 1 proto 50
>>      0     0 ACCEPT     all  --  *      eth0 192.168.25.0/24
>> <http://192.168.25.0/24> 192.168.22.0/24 <http://192.168.22.0/24>
>> policy match dir out pol ipsec reqid 1 proto 50
>>
>> Chain OUTPUT (policy ACCEPT 40 packets, 3976 bytes)
>>   pkts bytes target     prot opt in     out     source
>> destination
>>      0     0 ACCEPT     all  --  *      eth0 192.168.25.0/24
>> <http://192.168.25.0/24> 192.168.22.0/24 <http://192.168.22.0/24>
>> policy match dir out pol ipsec reqid 1 proto 50
>> root at lssimgw1:/usr/local/etc#
>> ------------------------------------------------------------
>> --------------------------------------------
>>
>> - so once we have the above fw rules in place in the INPUT/OUTPUT
>> chain,..we can access the GW1-lan-ip from PC2 via the ipsec tunnel
>> successfully...
>> - The similar observation is also made for using the lefthostaccess
>> option on GW2 too..
>>
>>
>>
>> Now if i use "righthostaccess=yes"...i dont see any rules getting added
>> in the INPUT/OUTPUT chain...neither in GW1 or in GW2
>>
>> - So my query is: whats the use of the option
>> "righthostaccess=yes"...where and when do we use this option?
>>
>>
>> thanks & regards
>> Rajiv
>>
>>
>>
>>
> --
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Open Source VPN Solution!          www.strongswan.org
> Institute for Networked Solutions
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[INS-HSR]==
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171120/0255a638/attachment.html>


More information about the Users mailing list