[strongSwan] TCP Retransmission problems with Android client connecting behind home router
I have my strongSwan server behind my home Verizon router and connect to it with my Android phone running the strongSwan client. So my Android client connects over LTE to my home router and is forwarded to my strongSwan server which then forwards the requests back out the home router to the intended destination and then sends it back to the client over the tunnel. I am having a problem where websites take a very long time to load and will sometimes timeout or not load fully. I see in Wireshark that there are a lot of TCP Retransmissions FIN/ACK going on. I assume this is some kind of latency issue, but I can't seem to figure out how to fix it. If I connect to my home network and the strongSwan server through my Wi-Fi connection I do not see this issue, pointing to it being some kind of latency problem. This is not an mtu/mss problem since I already fixed that by setting the mss to 1300. Is there a way that I could fix this by tuning the TCP options? Thanks,___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] VPN not routing traffic, how to troubleshoot?
My point to point VPN suddenly stopped pushing packets through the VPN from other servers on the LAN. I can telnet to the other side from the strongswan server, but the web servers can't. The VPN is up and no errors or warning are revealed with debug =2. I can see traffic from the web servers hitting the strongswan server with tcpdump. I don't recall changing anything, but you something obviously is wrong. How does one being troubleshooting this? Thanks for your input. Aaron ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Windows 2008 R2 to Linux connection issues
That was it. So simple it seems silly, but I don't know that I would have ever come across it myself. Thanks! -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: Tuesday, March 10, 2015 9:49 AM To: Rightler, Dwayne R. Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Windows 2008 R2 to Linux connection issues Hi, > 13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) > N(NATD_D_IP) ] 13[NET] sending packet: from 10.1.186.35[500] to > 10.1.186.174[500] (432 bytes) 17[KNL] WFP MM failure: 10.1.186.35/32 > === 10.1.186.174/32, 0x3601, filterId 0 Have you disabled the IKEEXT Windows IKE service? The service must be disabled, as it binds to the same UDP ports and intercepts packets. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Windows 2008 R2 to Linux connection issues
Hi, > 13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) > ] > 13[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes) > 17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, > filterId 0 Have you disabled the IKEEXT Windows IKE service? The service must be disabled, as it binds to the same UDP ports and intercepts packets. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Windows 2008 R2 to Linux connection issues
Windows firewall is off, IPTables is allowing connections. I would hope it's a
simple configuration issue, but I can't put my finger on it. Connections from
linux to linux work. Any help would be appreciated.
Windows side: Swanctl.conf
connections {
host-to-host {
local_addrs = 10.1.186.35
remote_addrs = 10.1.186.174
local {
auth = pubkey
certs = stl-dfusapp-80.crt
id =
"C=US,ST=Missouri,O=Company,OU=DBA Team,CN=stl-dfusapp-80"
}
remote {
auth = pubkey
id =
"C=US,ST=Missouri,O=Company,OU=DBA Team,CN=stl-dfusadb-20"
}
children {
stl-dfusapp-80_stl-dfusadb-20 {
start_action =
start
}
}
version = 2
mobike = yes
reauth_time = 60m
rekey_time = 20m
proposals = aes128-sha256-modp2048
}
}
Linux side: ipsec.conf
conn stl-dfusadb-20_stl-dfusapp-80
left=stl-dfusadb-20
leftcert=stl-dfusadb-20.crt
leftid="C=US,ST=Missouri,O=Company,OU=DBA Team,CN=stl-dfusadb-20"
right=stl-dfusapp-80
rightid="C=US,ST=Missouri,O=Company,OU=DBA Team,CN=stl-dfusapp-80"
auto=add
Windows output:
00[DMN] Starting IKE service charon-svc (strongSwan 5.2.2, Windows Server 6.1.76
01 (SP 1.0)
00[LIB] loaded plugins: charon-svc nonce x509 pubkey pkcs1 pem openssl kernel-wf
p kernel-iph socket-win vici
00[LIB] unable to load 5 plugin features (5 due to unmet dependencies)
00[JOB] spawning 16 worker threads
11[CFG] loaded certificate 'C=US, ST=Missouri, O=Company, OU=DBA Tea
m, CN=stl-dfusapp-80'
08[CFG] loaded certificate 'C=US, ST=Missouri, L=St. Louis, O=Compan
y, OU=DBA Team, CN=strongswanCA'
09[CFG] loaded RSA private key
13[CFG] added vici connection: host-to-host
09[CFG] vici initiate 'stl-dfusapp-80_stl-dfusadb-20'
13[IKE] initiating IKE_SA host-to-host[1] to 10.1.186.174
13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
13[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, filterId
0
08[IKE] retransmit 1 of request with message ID 0
08[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, filterId
0
16[IKE] retransmit 2 of request with message ID 0
16[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, filterId
0
13[IKE] retransmit 3 of request with message ID 0
13[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, filterId
0
10[IKE] retransmit 4 of request with message ID 0
10[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, filterId
0
06[IKE] retransmit 5 of request with message ID 0
06[NET] sending packet: from 10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
17[KNL] WFP MM failure: 10.1.186.35/32 === 10.1.186.174/32, 0x3601, filterId
0
13[IKE] giving up after 5 retransmits
13[IKE] establishing IKE_SA failed, peer not responding
Linux log:
Mar 10 09:16:01 stl-dfusadb-20 charon: 16[NET] received packet: from
10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
Mar 10 09:16:01 stl-dfusadb-20 charon: 16[ENC] parsed IKE_SA_INIT request 0 [
SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Mar 10 09:16:01 stl-dfusadb-20 charon: 16[IKE] 10.1.186.35 is initiating an
IKE_SA
Mar 10 09:16:01 stl-dfusadb-20 charon: 16[IKE] sending cert request for "C=US,
ST=Missouri, L=St. Louis, O=Company, OU=DBA Team, CN=strongswanCA"
Mar 10 09:16:01 stl-dfusadb-20 charon: 16[ENC] generating IKE_SA_INIT response
0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Mar 10 09:16:01 stl-dfusadb-20 charon: 16[NET] sending packet: from
10.1.186.174[500] to 10.1.186.35[500] (465 bytes)
Mar 10 09:16:31 stl-dfusadb-20 charon: 11[JOB] deleting half open IKE_SA after
timeout
Mar 10 09:16:43 stl-dfusadb-20 charon: 13[NET] received packet: from
10.1.186.35[500] to 10.1.186.174[500] (432 bytes)
Mar 10 09:16:43 stl-dfusadb-20 charon: 13[ENC] parsed IKE_SA_INIT request 0 [
SA KE No N(NATD_
Re: [strongSwan] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
Hi,
Sorry for my previous mail, this time with some content:
> I have only started running into this since we started using more than
> one subnet in the left side of the connection.
> leftsubnet=10.176.0.0/13,10.130.0.0/16
> rightsubnet=192.168.0.0/16
> Iona-VPN-FW[1]: IKEv2 SPIs: 550d0c34bc66ce4e_i* da285a283fb7a4d1_r, rekeying
> in 23 hours
> Iona-VPN-FW{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: ccb6a085_i ad93852a_o
> Iona-VPN-FW{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 360 bytes_o (9 pkts,
> 2965s ago), rekeying in 33 seconds
> Iona-VPN-FW{1}: 10.176.0.0/13 === 192.168.0.0/16
> Iona-VPN-FW{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c01ce92f_i 0a7d4641_o
> Iona-VPN-FW{2}: AES_CBC_128/HMAC_SHA1_96, 2479 bytes_i (17 pkts, 3272s
> ago), 4873 bytes_o (15 pkts, 3272s ago), rekeying in 2 seconds
> Iona-VPN-FW{2}: 10.130.0.0/16 === 192.168.0.0/16
Actually, what you have configured and what got negotiated doesn't
really match. If you have multiple subnets in a connection, these should
get negotiated in a single CHILD_SA. However, you have multiple
CHILD_SAs, most likely because your peer prefers to negotiate that.
You may try to configure separate CHILD_SAs for your subnets. With
ipsec.conf, you'll have to define separate "conn" entries with the same
base settings, but different subnet configurations. charon automatically
merges such configurations to negotiate them under the same IKE_SA.
> Mar 4 16:58:14 ip-10-180-0-12 charon: 16[ENC] generating CREATE_CHILD_SA
> request 2 [ N(REKEY_SA) SA No TSi TSr ]
> Mar 4 16:58:14 ip-10-180-0-12 charon: 16[NET] sending packet: from
> 10.180.0.12[4500] to 2.2.2.2[4500] (332 bytes)
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[NET] received packet: from
> 2.2.2.2[4500] to 10.180.0.12[4500] (236 bytes)
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[ENC] parsed CREATE_CHILD_SA
> response 2 [ SA No TSi TSr ]
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 10.176.0.0/13 === 192.168.0.0/16 out (mark 0/0x) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x) for reqid 2, the same
> policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 fwd (mark 0/0x) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 10.176.0.0/13 === 192.168.0.0/16 out (mark 0/0x) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x) for reqid 2, the same
> policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[CFG] unable to install policy
> 192.168.0.0/16 === 10.176.0.0/13 fwd (mark 0/0x) for reqid 2, the
> same policy for reqid 1 exists
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[IKE] unable to install IPsec
> policies (SPD) in kernel
> Mar 4 16:58:14 ip-10-180-0-12 charon: 09[IKE] failed to establish CHILD_SA,
> keeping IKE_SA
Because of this mismatch between configuration and negotiated SAs, it
seems that when rekeying the selectors negotiated do not match the
previous CHILD_SA, but the other one separately negotiated.
I think you should change your configuration to use separate CHILD_SAs,
or try to negotiate all subnets under a single CHILD_SA on the Cisco
side. If that doesn't work, you may try a build from git sources; we
recently merged changes that avoid these policy conflicts. But most
likely you'll end up with the wrong selectors after rekeying the
CHILD_SA.
Regards
Martin
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] unable to install policy 192.168.0.0/16 === 10.176.0.0/13 in (mark 0/0x00000000) for reqid 2, the same policy for reqid 1 exists
On Sam, 2015-03-07 at 21:52 +, Tormod Macleod wrote:
> Hello,
>
> I'm getting the above error when rekeying. I think it might be related to
> issue #431? I've tried the workaround of setting reauth=no but this did not
> resolve the issue. I have only started running into this since we started
> using more than one subnet in the left side of the connection.
>
> If no traffic goes between 10.130.0.0/16 === 192.168.0.0/16 and that tunnel
> is never brought up the other tunnel will remain up and rekey without any
> problem. However, as soon as traffic goes between 10.130.0.0/16 ===
> 192.168.0.0/16 the next rekey fails and both tunnels are brought down. If I
> wait a few seconds and then send traffic from the right the tunnel(s) will
> come back up but traffic from the left never re-establishes either tunnel.
> Here's the log
> leftsubnet=10.176.0.0/13,10.130.0.0/16
> leftid=1.1.1.1
> leftfirewall=yes
> right=2.2.2.2
> rightsubnet=192.168.0.0/16
> rightid=2.2.2.2
> auto=start
> ike=aes128-md5-modp1536
> esp=aes128-sha1
> reauth=no
>
>
> Here's the log entry from the device on the right (Cisco ASA 9.1(3))
>
> Mar 4 17:01:19 [10.1.1.12.2.2] Mar 04 2015 17:01:19 Iona-VPN-FW :
> %ASA-4-113019: Group = 1.1.1.1, Username = 1.1.1.1, IP = 1.1.1.1, Session
> disconnected. Session Type: LAN-to-LAN, Duration: 0h:58m:34s, Bytes xmt:
> 2479, Bytes rcv: 5233, Reason: Lost Service
>
> This is the status just prior to rekeying
>
> Wed Mar 4 16:58:12 GMT 2015
> Status of IKE charon daemon (strongSwan 5.2.2, Linux
> 2.6.32-504.8.1.el6.x86_64, x86_64):
> uptime: 55 minutes, since Mar 04 16:02:59 2015
> malloc: sbrk 270336, mmap 0, used 215968, free 54368
> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 3
> loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem
> fips-pr
> f gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown
> xauth-generic unity
> Listening IP addresses:
> 10.180.0.12
> Connections:
> Iona-VPN-FW: 10.180.0.12...2.2.2.2 IKEv2
> Iona-VPN-FW: local: [1.1.1.1] uses pre-shared key authentication
> Iona-VPN-FW: remote: [2.2.2.2] uses pre-shared key authentication
> Iona-VPN-FW: child: 10.176.0.0/13 10.130.0.0/16 === 192.168.0.0/16 TUNNEL
> Security Associations (1 up, 0 connecting):
> Iona-VPN-FW[1]: ESTABLISHED 55 minutes ago,
> 10.180.0.12[1.1.1.1]...2.2.2.2[2.2.2.2]
> Iona-VPN-FW[1]: IKEv2 SPIs: 550d0c34bc66ce4e_i* da285a283fb7a4d1_r, rekeying
> in 23 hours
> Iona-VPN-FW[1]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_SHA1/MODP_1536
> Iona-VPN-FW{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: ccb6a085_i ad93852a_o
> Iona-VPN-FW{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 360 bytes_o (9 pkts,
> 2965s ago), rekeying in 33 seconds
> Iona-VPN-FW{1}: 10.176.0.0/13 === 192.168.0.0/16
> Iona-VPN-FW{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c01ce92f_i 0a7d4641_o
> Iona-VPN-FW{2}: AES_CBC_128/HMAC_SHA1_96, 2479 bytes_i (17 pkts, 3272s
> ago), 4873 bytes_o (15 pkts, 3272s ago), rekeying in 2 seconds
> Iona-VPN-FW{2}: 10.130.0.0/16 === 192.168.0.0/16
>
> Shortly afterwards it's like this
>
> Wed Mar 4 16:58:42 GMT 2015
> Status of IKE charon daemon (strongSwan 5.2.2, Linux
> 2.6.32-504.8.1.el6.x86_64, x86_64):
> uptime: 55 minutes, since Mar 04 16:02:58 2015
> malloc: sbrk 270336, mmap 0, used 216192, free 54144
> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 4
> loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem
> fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke
> updown xauth-generic unity
> Listening IP addresses:
> 10.180.0.12
> Connections:
> Iona-VPN-FW: 10.180.0.12...2.2.2.2 IKEv2
> Iona-VPN-FW: local: [1.1.1.1] uses pre-shared key authentication
> Iona-VPN-FW: remote: [2.2.2.2] uses pre-shared key authentication
> Iona-VPN-FW: child: 10.176.0.0/13 10.130.0.0/16 === 192.168.0.0/16 TUNNEL
> Security Associations (1 up, 0 connecting):
> Iona-VPN-FW[1]: ESTABLISHED 55 minutes ago,
> 10.180.0.12[1.1.1.1]...2.2.2.2[2.2.2.2]
> Iona-VPN-FW[1]: IKEv2 SPIs: 550d0c34bc66ce4e_i* da285a283fb7a4d1_r, rekeying
> in 22 hours
> Iona-VPN-FW[1]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_SHA1/MODP_1536
> Iona-VPN-FW[1]: Tasks queued: CHILD_REKEY
> Iona-VPN-FW[1]: Tasks active: CHILD_REKEY
> Iona-VPN-FW{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: ccb6a085_i ad93852a_o
> Iona-VPN-FW{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 360 bytes_o (9 pkts,
> 2996s ago), rekeying in 2 seconds
> Iona-VPN-FW{1}: 10.176.0.0/13 === 192.168.0.0/16
> Iona-VPN-FW{2}: REKEYING, TUNNEL, expires in 4 minutes
> Iona-VPN-FW{2}: 10.130.0.0
Re: [strongSwan] Performance with lots of tunnels and (XFRM) policies
Noel, > I would like to know how the performance of strongswan/Linux is with > about 1000 established tunnels and ~3000 (XFRM) policies. I think XFRM policy lookup in the kernel scales fine, handling ~3000 policies shouldn't be a problem at all. > How much traffic can be forwarded? Is the performance hit because of > the large number of policies in any way significant? I don't think so; IPsec throughput is mostly limited by your raw crypto performance. Of course working on many SAs may reduce the efficiency of your CPU caches compared to a single SA carrying all the traffic. In the end you'll have to test your setup on your hardware to get any useful answers. Given that some strongSwan installations handle ~100'000 tunnels just fine, scaling to 1000 active tunnels is no rocket science. Regards Martin signature.asc Description: This is a digitally signed message part ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] High availability failover problem
> Then you should check if ClusterIP works as expected, and both on the > inbound and outbound paths the ESP packets hit both nodes. To clarify, on the outbound path this of course is plain traffic subject to ESP encapsulation. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] High availability failover problem
Aleksey, > when I test failover [...], traffic won't flow through standby > node until rekey on child SA is done To me this sound like an ESP sequence number issue. I assume you have patched your kernel to include our ClusterIP IPsec extensions, as discussed at [1]. You may find some never patches in the ha-* tags/branches at [2]. Then you should check if ClusterIP works as expected, and both on the inbound and outbound paths the ESP packets hit both nodes. If this is the case, ClusterIP can keep ESP sequence numbers in sync on the passive node. If that all works as expected, try to compare the sequence numbers before and after failover. Linux drops packets with an already used sequence number silently, but /proc/net/xfrm_stats (requires CONFIG_XFRM_STATISTICS) has some counters that can help in analyzing why packets get dropped. Regards Martin [1]https://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability [2]http://git.strongswan.org/?p=linux-dumm.git;a=summary ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Some sites don't load or timeout because of IP fragmentation problems
It looks like I have to enter this from the command line - iptables -t mangle -A FORWARD -o enp0s3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1300:1536 -j TCPMSS --set-mss 1300 Seems to solve the MSS issue, but now sites take a VERY long time to load and will sometimes timeout. I see a lot of TCP Retransmission messages. Any ideas? On Tuesday, March 10, 2015 4:06 AM, Mark M wrote: for some reason it stopped working after I restarted the server, On Tuesday, March 10, 2015 1:45 AM, Mark M wrote: I found that this iptables rule works- -A FORWARD -o enp0s3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1300:1536 -j TCPMSS --set-mss 1300 Now I am seeing a lot of TCP Retransmissions packets and sites are slow to slow. Any ideas? On Tuesday, March 10, 2015 1:06 AM, Mark M wrote: I confirmed with Wireshark that is advertises a MSS above 1300 for some reason. Something strange is going on here, why would both methods not work? On Tuesday, March 10, 2015 12:24 AM, Mark M wrote: I removed firewalld to make it more simple, here is what it looks like and still no luck- [root@CENTOS7 ~]# iptables -LChain INPUT (policy ACCEPT)target prot opt source destinationACCEPT all -- anywhere anywhere state RELATED,ESTABLISHEDACCEPT icmp -- anywhere anywhereACCEPT all -- anywhere anywhereACCEPT tcp -- anywhere anywhere state NEW tcp dpt:sshACCEPT udp -- anywhere anywhere udp dpt:isakmpACCEPT udp -- anywhere anywhere udp dpt:ipsec-nat-tREJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT)target prot opt source destinationACCEPT all -- 192.168.9.1 anywhere policy match dir in pol ipsec reqid 1 proto espACCEPT all -- anywhere 192.168.9.1 policy match dir out pol ipsec reqid 1 proto espACCEPT all -- anywhere anywhereTCPMSS tcp -- 192.168.9.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300TCPMSS tcp -- 192.168.1.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300 Chain OUTPUT (policy ACCEPT)target prot opt source destination[root@CENTOS7 ~]# On Monday, March 9, 2015 9:57 PM, Mark M wrote: Noel, Does not seem to be working but I don't know if it is configured properly, i think firewalld makes it a mess. Does this look right? [root@CENTOS7 ~]# iptables -LChain INPUT (policy ACCEPT)target prot opt source destinationACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHEDACCEPT all -- anywhere anywhereINPUT_direct all -- anywhere anywhereINPUT_ZONES_SOURCE all -- anywhere anywhereINPUT_ZONES all -- anywhere anywhereACCEPT icmp -- anywhere anywhereREJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT)target prot opt source destinationACCEPT all -- 192.168.9.1 anywhere policy match dir in pol ipsec reqid 2 proto espACCEPT all -- anywhere 192.168.9.1 policy match dir out pol ipsec reqid 2 proto espACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHEDACCEPT all -- anywhere anywhereFORWARD_direct all -- anywhere anywhereFORWARD_IN_ZONES_SOURCE all -- anywhere anywhereFORWARD_IN_ZONES all -- anywhere anywhereFORWARD_OUT_ZONES_SOURCE all -- anywhere anywhereFORWARD_OUT_ZONES all -- anywhere anywhereACCEPT icmp -- anywhere anywhereREJECT all -- anywhere anywhere reject-with icmp-host-prohibitedTCPMSS tcp -- 192.168.1.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300TCPMSS tcp -- 192.168.9.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300 Chain OUTPUT (policy ACCEPT)target prot opt source destinationOUTPUT_direct all -- anywhere anywhere Chain FORWARD_IN_ZONES (1 references)target prot opt source destinationFWDI_public all -- anywhere anywhere [goto]FWDI_public all -- anywhere anywhere [goto]FWDI_public all -- anywhere anywhere [goto] Chain FORWARD_IN_ZONES_SOURCE (1 references)target prot opt source destination Chain FORWARD_OUT_ZONES (1 references)target prot opt source destinationFWDO_public all -- anywhere anywhere [goto]FWDO_publi
Re: [strongSwan] Some sites don't load or timeout because of IP fragmentation problems
for some reason it stopped working after I restarted the server, On Tuesday, March 10, 2015 1:45 AM, Mark M wrote: I found that this iptables rule works- -A FORWARD -o enp0s3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1300:1536 -j TCPMSS --set-mss 1300 Now I am seeing a lot of TCP Retransmissions packets and sites are slow to slow. Any ideas? On Tuesday, March 10, 2015 1:06 AM, Mark M wrote: I confirmed with Wireshark that is advertises a MSS above 1300 for some reason. Something strange is going on here, why would both methods not work? On Tuesday, March 10, 2015 12:24 AM, Mark M wrote: I removed firewalld to make it more simple, here is what it looks like and still no luck- [root@CENTOS7 ~]# iptables -LChain INPUT (policy ACCEPT)target prot opt source destinationACCEPT all -- anywhere anywhere state RELATED,ESTABLISHEDACCEPT icmp -- anywhere anywhereACCEPT all -- anywhere anywhereACCEPT tcp -- anywhere anywhere state NEW tcp dpt:sshACCEPT udp -- anywhere anywhere udp dpt:isakmpACCEPT udp -- anywhere anywhere udp dpt:ipsec-nat-tREJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT)target prot opt source destinationACCEPT all -- 192.168.9.1 anywhere policy match dir in pol ipsec reqid 1 proto espACCEPT all -- anywhere 192.168.9.1 policy match dir out pol ipsec reqid 1 proto espACCEPT all -- anywhere anywhereTCPMSS tcp -- 192.168.9.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300TCPMSS tcp -- 192.168.1.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300 Chain OUTPUT (policy ACCEPT)target prot opt source destination[root@CENTOS7 ~]# On Monday, March 9, 2015 9:57 PM, Mark M wrote: Noel, Does not seem to be working but I don't know if it is configured properly, i think firewalld makes it a mess. Does this look right? [root@CENTOS7 ~]# iptables -LChain INPUT (policy ACCEPT)target prot opt source destinationACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHEDACCEPT all -- anywhere anywhereINPUT_direct all -- anywhere anywhereINPUT_ZONES_SOURCE all -- anywhere anywhereINPUT_ZONES all -- anywhere anywhereACCEPT icmp -- anywhere anywhereREJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT)target prot opt source destinationACCEPT all -- 192.168.9.1 anywhere policy match dir in pol ipsec reqid 2 proto espACCEPT all -- anywhere 192.168.9.1 policy match dir out pol ipsec reqid 2 proto espACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHEDACCEPT all -- anywhere anywhereFORWARD_direct all -- anywhere anywhereFORWARD_IN_ZONES_SOURCE all -- anywhere anywhereFORWARD_IN_ZONES all -- anywhere anywhereFORWARD_OUT_ZONES_SOURCE all -- anywhere anywhereFORWARD_OUT_ZONES all -- anywhere anywhereACCEPT icmp -- anywhere anywhereREJECT all -- anywhere anywhere reject-with icmp-host-prohibitedTCPMSS tcp -- 192.168.1.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300TCPMSS tcp -- 192.168.9.0/24 anywhere tcp flags:SYN,RST/SYN TCPMSS set 1300 Chain OUTPUT (policy ACCEPT)target prot opt source destinationOUTPUT_direct all -- anywhere anywhere Chain FORWARD_IN_ZONES (1 references)target prot opt source destinationFWDI_public all -- anywhere anywhere [goto]FWDI_public all -- anywhere anywhere [goto]FWDI_public all -- anywhere anywhere [goto] Chain FORWARD_IN_ZONES_SOURCE (1 references)target prot opt source destination Chain FORWARD_OUT_ZONES (1 references)target prot opt source destinationFWDO_public all -- anywhere anywhere [goto]FWDO_public all -- anywhere anywhere [goto]FWDO_public all -- anywhere anywhere [goto] Chain FORWARD_OUT_ZONES_SOURCE (1 references)target prot opt source destination Chain FORWARD_direct (1 references)target prot opt source destination Chain FWDI_public (3 references)target prot opt source destinationFWDI_publ
