Date: Sun, 23 Mar 2014 11:23:06 -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) [[RESOLVED]] Message-ID: <532F0A6A.7040003@denninger.net> In-Reply-To: <532F0469.10202@denninger.net> References: <532E123B.3060702@denninger.net> <532E6A9D.9040609@denninger.net> <532F0469.10202@denninger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 3/23/2014 10:57 AM, Karl Denninger wrote: > > On 3/23/2014 12:01 AM, Karl Denninger wrote: >> >> On 3/22/2014 5:44 PM, Karl Denninger wrote: >>> FreeBSD-STABLE 10 r263037M >>> >>> >>> 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. >> > Or not.... > > Now the packets just disappear entirely. Still investigating.... > Got it. With the patches you have to be verrrry careful with the nat, and make sure you first explicitly *exclude* NAT processing from IPSEC-related packets (which DO have their tags properly carried forward now) and then you must also explicitly process NAT *outbound only* for IPSEC-outbound packets that arrive coming inward. In other words, with pr185876 on your system, assuming 192.168.2.0/24 is your IPSEC pool and the Internet-accessible interface is em1, you need the following fragments if you want NAT to the Internet at-large to work for IPSEC-connected clients: 01700 divert 8668 ip4 from any to any not ipsec via em1 01705 divert 8668 ip4 from 192.168.2.0/24 to any ipsec xmit em1 To process all NAT-related traffic EXCEPT outbound IPSEC-related, and then to explicitly process *only* outbound IPSEC related packets (and not inbound ones, which are picked up by the first rule already) That works. pr185876's fixes must be in your system, and because they change header definitions you must rebuild world, not just the kernel. -- -- Karl karl@denninger.net [-- Attachment #2 --] 0 *H 01 0 + 0 *H O0K030 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 130824190344Z 180823190344Z0[1 0 UUS10UFlorida10UKarl Denninger1!0 *H karl@denninger.net0"0 *H 0 bi՞] MNԿawx?`)'ҴcWgR@BlWh+ u}ApdCF JVй~FOL }EW^bچYp3K& ׂ(R lxڝ.xz?6 &nsJ +1v9 v/( kqĪp[vjcK%fϻe?iq]z lyzFO'ppdX//Lw(3 JI A*S#՟H[f|CGqJKoo y.oEuOw$ /섀$삻J9b|A P~8]D1YI<"""Y^T2iQ2 b yH)] Ƶ0y$ _N 6XqMC 9 XgώjGTP"#nˋ"Bk1 00 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U |8 ˴d[20 U #0]Af4 U3x&^"408 `HB+)https://cudasystems.net:11443/revoked.crl0 *H gBwH] j\x`( &gW32"Uf^. ^Iϱ k!DQA g{(w /)\N'[ oRW @C HO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq aʷ?rk$^9TIa!kh,D -ct1 0001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 + ;0 *H 1 *H 0 *H 1 140323162306Z0# *H 1"`TY +0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H 6G>EuB4Lu߽ޱ MIA)Q>~/BEuyW"v`TBX~˭_ C ow3>WsFKDi -m&KFPBgT5giWf3 foI pqm. 0ʳL<qS1J:_E8F#<P.@U^Z lprC`.Szb SBFu&:t<eӯyt-9B7kٿfRn:9V KnlǏr>F-㊩Ҩh7 CQ#;PUu$Z =?qf՜*$PTTPUl$ ɈPK \:嬦Xu 3`&E{CzfG טŠh[\]I4$C}>%7 1lz\4顄']4@ޡ_Dqq3+kVԈ[HC~s7help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?532F0A6A.7040003>