Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Mar 2014 00:01:17 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-net@freebsd.org
Subject:   Re: Strongswan problem (used to work for client NAT to the Internet,  no longer does)
Message-ID:  <532E6A9D.9040609@denninger.net>
In-Reply-To: <532E123B.3060702@denninger.net>
References:  <532E123B.3060702@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.

--------------ms070109060009060403070404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


On 3/22/2014 5:44 PM, Karl Denninger wrote:
> FreeBSD-STABLE 10 r263037M
>
> Configuration has outside IPSEC connections coming in to Strongswan=20
> which should then be able to NAT back out to the Internet.  The=20
> premise here is that "roaming" people may connect to this box and=20
> obtain both access to "inside" resources and outside Internet access,=20
> since the client points default at the IPSEC'd connection.
>
> This used to work on 9.1, but am uncertain whether it has since.
>
> It does NOT under 10.0.
>
> [root@Gateway /disk/karl]# ipsec status
> Security Associations (1 up, 0 connecting):
>         XX[3]: ESTABLISHED 5 minutes ago, x.x.x.x[C=3DUS, ST=3Dxx, O=3D=
xxx,=20
> CN=3Dthe.dom.ain, E=3Dxxxxx]...172.56.20.235[xxxxx]
>         BB10{3}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c90f5d36_i=20
> 4160832e_o
>         BB10{3}:   0.0.0.0/0 =3D=3D=3D 192.168.2.1/32
> [root@Gateway /disk/karl]#
>
> Ok, so theoretically there's a default route from the device, which is =

> fine.  And the device (on 192.168.2.1, which was dynamically assigned=20
> from a pool) can see anything internal on this external box (x.x.x.x)  =

> I can successfully mount a samba share, for example, on a server that=20
> is inside the firewall and I can also see the DNS resolver on the=20
> gateway.
>
> However, let's now try to go out to an external location via an IP=20
> address.  We'll watch it using TCPDUMP on em1, the interface that the=20
> packets are going to be emitted from toward the Internet:
>
> [root@NewFS /disk/karl]# tcpdump -i em1 host 173.245.6.228
>
>
> 17:07:06.524487 IP 192.168.2.1.14927 > 173.245.6.228.http: Flags [S],=20
> seq 150879940, win 65535, options [mss 1188,nop,wscale=20
> 6,sackOK,nop,nop,nop,nop,TS val 778723856 ecr 0], length 0
> 17:07:19.741732 IP 192.168.2.1.16697 > 173.245.6.228.http: Flags [S],=20
> seq 2513053141, win 65535, options [mss 1188,nop,wscale=20
> 6,sackOK,nop,nop,nop,nop,TS val 778723883 ecr 0], length 0
> 17:07:20.797330 IP 192.168.2.1.16697 > 173.245.6.228.http: Flags [S],=20
> seq 2513053141, win 65535, options [mss 1188,nop,wscale=20
> 6,sackOK,nop,nop,nop,nop,TS val 778723884 ecr 0], length 0
> 17:07:22.706839 IP 192.168.2.1.16697 > 173.245.6.228.http: Flags [S],=20
> seq 2513053141, win 65535, options [mss 1188,nop,wscale=20
> 6,sackOK,nop,nop,nop,nop,TS val 778723888 ecr 0], length 0
>
> Ehhh...... that's no good.  natd never gets the packets and never=20
> translates them; it sure looks like we're trying to blow a private IP=20
> number out the wire despite:
>
> 01700 divert 8668 ip4 from any to any via em1
> 01710 divert 8668 ip4 from 192.168.2.0/24 to any via em1
>
> and ahead of that (to prevent exactly this sort of thing)
>
> 01120 deny log ip from any to 192.168.0.0/16 via em1 not ipsec
>
> Which by the way does NOT log anything.
>
>
> net.inet.ip.fw.one_pass: 0
> net.inet.ip.fw.autoinc_step: 100
> net.inet.ip.fw.verbose: 1
> net.inet.ip.fw.verbose_limit: 0
> net.inet.ip.fw.default_rule: 65535
> net.inet.ip.fw.tables_max: 128
> net.inet.ip.fw.default_to_accept: 0
> net.inet.ip.fw.static_count: 108
> net.inet.ip.fw.enable: 1
> net.inet.ip.fw.dyn_buckets: 256
> net.inet.ip.fw.curr_dyn_buckets: 256
> net.inet.ip.fw.dyn_count: 3
> net.inet.ip.fw.dyn_max: 4096
> net.inet.ip.fw.dyn_ack_lifetime: 300
> net.inet.ip.fw.dyn_syn_lifetime: 20
> net.inet.ip.fw.dyn_fin_lifetime: 1
> net.inet.ip.fw.dyn_rst_lifetime: 1
> net.inet.ip.fw.dyn_udp_lifetime: 10
> net.inet.ip.fw.dyn_short_lifetime: 5
> net.inet.ip.fw.dyn_keepalive: 1
>
> one_pass is off.
>
> And there is nothing being blocked either; all the "deny" entries have =

> "log" on them and there's nothing showing up in the logfile (there's=20
> plenty of random people trying to port scan me that ARE showing up,=20
> however, so I know the log is working properly.)
>
> It *looks* like anything coming in through IPSEC and being decoded in=20
> there never goes through the ipfw chain at all.....
>
This may be addressed by PR185876.... checking.

--=20
-- Karl
karl@denninger.net



--------------ms070109060009060403070404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC
BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI
EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM
TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv
bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5
MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg
RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th
d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W
6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV
jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5
SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY
5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8
Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4
GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci
WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN
nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB
o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg
hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4
+LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG
CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy
bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO
31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c
L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1
YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD
pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE
f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk
YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD
VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2
aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMjMwNTAxMTdaMCMGCSqGSIb3DQEJBDEW
BBSnF4gpq+QxzBnFZZdMYxzHyLB9rjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT
EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq
hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG
9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV
BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk
YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh
c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAS3ji6QF0FOFdasCNiHcA4YzMiQ4Q
xQLV4ftxCXMIN/MHarvO/W3ArN8eaH+WAUpaa6Egq7dkcUYVNEn6JYjqmsD+YxN4L5xVHQ7X
FnXghuSXAjCUf0/HtN5xJaYC4mKvpAscW1ss2DiapBZ/YSjUSpHy9xWCzCIAwT2bTU1jX9eb
wsjfKeS858+x4tzyX3Z6yn44W9naHYUqPdX8BO5HawsuPrjTNhqx9hJ5rUWmnn3epqfWzYqg
qsFQpKkmadSW71RjY+VXXDV8d8pL9CGVPLj1R9ZYgsqf9p/UP1wIxOIgG+sfNsDeO6BqFrgM
BLx20o0tOqJm3L94bZjrq33WTMYxrS882cgnXC9/ZWbSIlScDTVNntpYPRuRRzV0X51MK2Dj
XW/Ucx5vDERnRbrFXEVzyWWIXA6decWn9zdvoVMGjcorWm5RQCpnL6Y1wklDY2EEjJ7U9C+M
gsUDyL3mWv1M7F7hoCPr9+yu5e20Noe9XdjHsk20Tfgc6QExxVfjKzOF8Yg50cLTZTYoiUwK
BwYFyIDPyhRBy/wij+8A2x7D31j+3fzsXmCmjwNYV/mjtc3/WvmsRDfaIyXdx8aRHDgKjIcE
/5v1kLy9zqwXqT5hcCl5XIahxLfOE8oelbCyWrnN5FW7f1RFJ1YoSRqjeg16VnxU+DmfhLGp
G65Qf00AAAAAAAA=
--------------ms070109060009060403070404--





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?532E6A9D.9040609>