[strongSwan] VPN connection to Remote Fortigate Client
MOSES KARIUKI
kariukims at gmail.com
Fri Apr 12 09:47:57 CEST 2019
Thanks Tobias as always.
# Generated by iptables-save v1.6.1 on Fri Apr 12 06:50:35 2019
*mangle
:PREROUTING ACCEPT [97346:21879529]
:INPUT ACCEPT [97344:21878509]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [91143:10601255]
:POSTROUTING ACCEPT [91143:10601255]
-A FORWARD -s 10.28.2.0/24 -o ens4 -p tcp -m policy --dir in --pol ipsec -m
tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss
1360
COMMIT
# Completed on Fri Apr 12 06:50:35 2019
# Generated by iptables-save v1.6.1 on Fri Apr 12 06:50:35 2019
*nat
:PREROUTING ACCEPT [1357:77518]
:INPUT ACCEPT [1079:64346]
:OUTPUT ACCEPT [8044:522059]
:POSTROUTING ACCEPT [8044:522059]
-A POSTROUTING -s 10.28.2.0/24 -o ens4 -m policy --dir out --pol ipsec -j
ACCEPT
-A POSTROUTING -s 10.28.2.0/24 -o ens4 -j MASQUERADE
COMMIT
# Completed on Fri Apr 12 06:50:35 2019
# Generated by iptables-save v1.6.1 on Fri Apr 12 06:50:35 2019
*filter
:INPUT DROP [2:104]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:sshguard - [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -s 10.28.2.0/24 -d 10.138.0.4/32 -i ens4 -m policy --dir in --pol
ipsec --reqid 2 --proto esp -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -s 10.138.0.4/32 -d 10.28.2.0/24 -o ens4 -m policy --dir out
--pol ipsec --reqid 2 --proto esp -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j
ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG
--log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG
--log-prefix "[UFW BLOCK] "
-A ufw-before-forward -s 10.28.2.0/24 -m policy --dir in --pol ipsec
--proto esp -j ACCEPT
-A ufw-before-forward -d 10.28.2.0/24 -m policy --dir out --pol ipsec
--proto esp -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j
ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG
--log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min
--limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG
--log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p udp -m multiport --dports 500,4500 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -m comment --comment
"\'dapp_OpenSSH\'" -j ACCEPT
-A ufw-user-input -s 200.1*.1*3.*/32 -j ACCEPT
-A ufw-user-input -s 200.1*.1*3.*/32 -p esp -j ACCEPT
-A ufw-user-input -s 200.1*.1*3.*/32 -p ah -j ACCEPT
-A ufw-user-input -s 200.1*.1*3.*/32 -p gre -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT
BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Fri Apr 12 06:50:35 2019
Thanks sir.
Regards,
Moses K
On Thu, Apr 11, 2019 at 7:36 PM Noel Kuntze
<noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
> Hi,
>
> Provide your nat rules in iptables/nftables (whatever you're using) or
> provide the complete rule set, as shown with `iptables-save`.
>
> Am 11.04.19 um 09:04 schrieb MOSES KARIUKI:
> > Hello Noel, Team,
> >
> > Any kind souls out there?
> > Please assist with the below question.
> >
> >
> > On Mon, Apr 8, 2019 at 3:22 PM MOSES KARIUKI <kariukims at gmail.com
> <mailto:kariukims at gmail.com>> wrote:
> >
> > Thanks a lot Noel. The connection is up and stable. Very helpful.
> > One more thing, the remote client is able to ping my private IP, but
> i am unable to ping his private IP address. I have checked and my routes
> seem OK. What do you suggest?
> >
> > Below is my status:
> >
> > */sudo ipsec statusall/*
> > Status of IKE charon daemon (strongSwan 5.6.3, Linux
> 4.18.0-1008-gcp, x86_64):
> > uptime: 28 seconds, since Apr 08 12:14:39 2019
> > malloc: sbrk 1622016, mmap 0, used 629024, free 992992
> > worker threads: 11 of 16 idle, 5/0/0/0 working, job queue:
> 0/0/0/0, scheduled: 5
> > loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random
> nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
> dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr
> kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2
> xauth-generic counters
> > Listening IP addresses:
> > 10.138.0.4
> > Connections:
> > televida: 10.138.0.4...200.**.***.*** IKEv2, dpddelay=30s
> > televida: local: [35.1**.2**.***] uses pre-shared key
> authentication
> > televida: remote: [200.**.***.***] uses pre-shared key
> authentication
> > televida: child: 10.138.0.0/20 <http://10.138.0.0/20> ===
> 10.28.2.0/24 <http://10.28.2.0/24> TUNNEL, dpdaction=clear
> >
> > Security Associations (1 up, 0 connecting):
> > televida[1]: ESTABLISHED 23 seconds ago,
> 10.138.0.4[35.1**.2**.***]...200.**.***.***[200.**.***.***]
> > televida[1]: IKEv2 SPIs: 055627d3eb22222f_i 081a1b696be14ad2_r*,
> pre-shared key reauthentication in 23 hours
> > televida[1]: IKE proposal:
> AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521
> > televida{2}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs:
> c5fb101f_i 82900426_o
> > televida{2}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0
> bytes_o, rekeying in 41 minutes
> > televida{2}: 10.138.0.4/32 <http://10.138.0.4/32> ===
> 10.28.2.0/24 <http://10.28.2.0/24>
> > kariukims at klick-001:~$ ping 10.28.2.9
> > PING 10.28.2.9 (10.28.2.9) 56(84) bytes of data.
> > ^C
> > --- 10.28.2.9 ping statistics ---
> > 3 packets transmitted, 0 received, 100% packet loss, time 56ms
> >
> >
> > Kind regards,
> > Moses K
> >
> > On Mon, Apr 8, 2019 at 3:09 PM MOSES KARIUKI <kariukims at gmail.com
> <mailto:kariukims at gmail.com>> wrote:
> >
> > Thanks a lot Noel. The connection is up and stable. Very
> helpful.
> > One more thing, the remote client is able to ping my private IP,
> but i am unable to ping his private IP address. I have checked and my
> routes seem OK. What do you suggest?
> >
> > Kind regards,
> > Moses K
> >
> >
> > On Thu, Apr 4, 2019 at 9:50 PM Noel Kuntze
> <noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
> >
> > Hi,
> >
> > You configured "rightsourceip=10.10.10.0/24 <
> http://10.10.10.0/24>" but that's supposed to be a site-to-site
> connection. Use rightsubnet instead.
> > rightsourceip is for assigning and requesting virtual IPs.
> The best way for you would be to migrate to swanctl instead.
> > Its configuration format is a lot clearer.
> >
> > Kind regards
> >
> > Noel
> >
> > Am 02.04.19 um 11:27 schrieb MOSES KARIUKI:
> > > Dear Tobias,
> > >
> > > :) :)
> > > I read the message. But I can't really interpret what
> setting is needed to make it work. I have listed my current configuration.
> I am still finding my way with Linux networking and Strongswan.
> > >
> > > Please assist. I will really appreciate and also offer
> assist others.
> > >
> > > regards,
> > > Moses
> > >
> > >
> > >
> > > On Tue, Apr 2, 2019 at 11:23 AM Tobias Brunner <
> tobias at strongswan.org <mailto:tobias at strongswan.org> <mailto:
> tobias at strongswan.org <mailto:tobias at strongswan.org>>> wrote:
> > >
> > > Hi Moses,
> > >
> > > > Apr 1 20:57:58 klick-001 charon: 11[IKE] expected a
> virtual IP
> > > > request, sending FAILED_CP_REQUIRED
> > >
> > > I guess reading is hard. Or is that message (that you
> explicitly marked
> > > in your email) really that unclear?
> > >
> > > Regards,
> > > Tobias
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190412/a36ff045/attachment-0001.html>
More information about the Users
mailing list