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 

[-- Attachment #1 --]

On 3/22/2014 5:44 PM, Karl Denninger wrote:
> FreeBSD-STABLE 10 r263037M
>
> Configuration has outside IPSEC connections coming in to Strongswan 
> which should then be able to NAT back out to the Internet.  The 
> premise here is that "roaming" people may connect to this box and 
> obtain both access to "inside" resources and outside Internet access, 
> 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=US, ST=xx, O=xxx, 
> CN=the.dom.ain, E=xxxxx]...172.56.20.235[xxxxx]
>         BB10{3}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c90f5d36_i 
> 4160832e_o
>         BB10{3}:   0.0.0.0/0 === 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 
> 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 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 
> address.  We'll watch it using TCPDUMP on em1, the interface that the 
> 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], 
> seq 150879940, win 65535, options [mss 1188,nop,wscale 
> 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], 
> seq 2513053141, win 65535, options [mss 1188,nop,wscale 
> 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], 
> seq 2513053141, win 65535, options [mss 1188,nop,wscale 
> 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], 
> seq 2513053141, win 65535, options [mss 1188,nop,wscale 
> 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 
> translates them; it sure looks like we're trying to blow a private IP 
> 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 
> plenty of random people trying to port scan me that ARE showing up, 
> however, so I know the log is working properly.)
>
> It *looks* like anything coming in through IPSEC and being decoded in 
> there never goes through the ipfw chain at all.....
>
This may be addressed by PR185876.... checking.

-- 
-- Karl
karl@denninger.net



[-- Attachment #2 --]
0	*H
010	+0	*H
O0K030
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1/0-	*H
	 customer-service@cudasystems.net0
130824190344Z
180823190344Z0[10	UUS10UFlorida10UKarl Denninger1!0	*H
	karl@denninger.net0"0
	*H
0
bi՞]MNԿawx?`)'ҴcWgR@BlWh+	u}ApdCFJVй~FOL}EW^bچYp3K&ׂ(R
lxڝ.xz?6&nsJ+1v9v/(kqĪp[vjcK%fϻe?iq]z
lyzFO'ppdX//Lw(3JIA*S#՟H[f|CGqJKooy.oEuOw$/섀$삻J9b|AP~8]D1YI<"""Y^T2iQ2b	yH)]	Ƶ0y$_N6XqMC 9՘	XgώjGTP"#nˋ"Bk100	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U|8˴d[20U#0]Af4U3x&^"408	`HB+)https://cudasystems.net:11443/revoked.crl0
	*H
gBwH]j\x`(&gW32"Uf^.^Iϱ
k!DQAg{(w/)\N'[oRW@CHO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq
aʷ?rk$^9TIa!kh,D-ct1
00010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1/0-	*H
	 customer-service@cudasystems.net0	+;0	*H
	1	*H
0	*H
	1
140323050117Z0#	*H
	1)1eLcȰ}0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1/0-	*H
	 customer-service@cudasystems.net0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1/0-	*H
	 customer-service@cudasystems.net0
	*H
Kxt]jw̉q	s7jmhJZk dqF4I%cx/Uu0OǴq%b[[,8a(J"=MMc_כ)ϱ_vz~8[*=Gk.>6yE}ަ͊P&iԖTccW\5|wK!<GXʟ?\ 6;jvҍ-:fܿxm}L1/<'\/ef"T
5MX=G5t_L+`]osoDgE\Ese\yŧ7oS+ZnQ@*g/5ICca/ȽZL^#6]DzMM1W+39e6(L
ȀA"X^`XWZD7#%Ƒ8
ά>ap)y\ķZUTE'V(Iz
zV|T9PM

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