[strongSwan] VPN connection to Remote Fortigate Client
MOSES KARIUKI
kariukims at gmail.com
Mon Apr 15 10:06:33 CEST 2019
Hello Noel,
Please see below as requested and advise. Thank you in advance
On Fri, Apr 12, 2019 at 10:47 AM MOSES KARIUKI <kariukims at gmail.com> wrote:
> Thanks Noel 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/20190415/4525c898/attachment-0001.html>
More information about the Users
mailing list