Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Mar 2014 17:44:11 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-net@freebsd.org
Subject:   Strongswan problem (used to work for client NAT to the Internet, no longer does)
Message-ID:  <532E123B.3060702@denninger.net>

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

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

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 premise=20
here is that "roaming" people may connect to this box and obtain both=20
access to "inside" resources and outside Internet access, since the=20
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=3Dx=
xx,=20
CN=3Dthe.dom.ain, E=3Dxxxxx]...172.56.20.235[xxxxx]
         BB10{3}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c90f5d36_i 4160832=
e_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=20
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 is=20
inside the firewall and I can also see the DNS resolver on the 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=20
"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.....

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



--------------ms090804020106020602070602
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
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMjIyMjQ0MTFaMCMGCSqGSIb3DQEJBDEW
BBSPxmgqculdslBLTHfYRIFQAK6NWjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT
EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq
hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG
9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV
BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk
YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh
c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIABQS1SNZBlItkh6SE6a8cLjW7RrEo
12syIF9jbYuy2UPOFVaiNTc4GiUv4QkoD/lkdn0v9Jwlu1x4htTF8ThO2ANFIcgMMTrcZ5z5
uIM7W7To+PktoBzqCWC6KUjc9AFgXN+6jke3fkwoe8NFYESib/j/84F8wAXuhyQba0QybaBL
ee4S773W1Qnt7oqYngqHHY8cjFE2yGWMVhY5e8DZDhdp79ut5NcJ74Kh2IwtglGHVWL4AQak
nxjK73b6FUGTGpHUxI+GMAYJIssDu62pglE+upkGREDpvQ8d0/LTb6MS0l74KNp5ukj/PxDX
jIHSeOFZGEqCQt3jiZF234Pcap7Ci9bshC1Tuqun5ZBWC1z6yFr65nHU5BJ5Qk39I+AxfWaE
a+FjqpYZXhobR/rKe/+nVar2CrNYB3EK9jxnknup54wwKVu134fRRzsIQFi3BvG2n+h/HVDw
Q1cAmQJJa/AY9YccIc5MBGBFP9dmvKCZWH/zLDeq5t75sQ8Rgrqfy/EbMGP8L33Ez72aFpEk
lzeORfnW/KsSJjmwUfQ1OlfuytR6slHLhBr0z2B8NXO1GuM0Ocpm/GPBXCXFfjZke1xc4WbK
RJMbtvrPCV+cFzm7oMnAgDhDWZCMuxlAxcGbjvWukq5jZOW4ATo7VRiAv6gMzwp1kxaYsOeP
FHCxITcAAAAAAAA=
--------------ms090804020106020602070602--





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