From a1297a53f7e3684effd0e554a50ebf07b4955e69 Mon Sep 17 00:00:00 2001 From: JACK Date: Mon, 25 Jan 2021 02:39:47 +0800 Subject: [PATCH] nptv6: T2518: Add document support for nat66 --- docs/_static/images/vyos_1_4_nat66_simple.png | Bin 0 -> 21021 bytes docs/configuration/nat/index.rst | 731 +---------------- docs/configuration/nat/nat44.rst | 733 ++++++++++++++++++ docs/configuration/nat/nat66.rst | 127 +++ docs/configuration/nat/nptv6.rst | 69 -- 5 files changed, 862 insertions(+), 798 deletions(-) create mode 100644 docs/_static/images/vyos_1_4_nat66_simple.png create mode 100644 docs/configuration/nat/nat44.rst create mode 100644 docs/configuration/nat/nat66.rst delete mode 100644 docs/configuration/nat/nptv6.rst diff --git a/docs/_static/images/vyos_1_4_nat66_simple.png b/docs/_static/images/vyos_1_4_nat66_simple.png new file mode 100644 index 0000000000000000000000000000000000000000..d7c54115e802e9add71090b082e3e03e6ba369ef GIT binary patch literal 21021 zcmZ_01z40_*EW11Dte=&gpv*dQqo-p0+JE}4k-voOAQ?c(jYD3fQo>0H$x~PEg&7E zGz>8G(ENMG`+dIW{l4S(IF#X1q@hF;lz? zyZPzo@<+Yg!D{U4bJrYCmoe*L(SQ#*%Qfy6$bV{=SFpi{R~{{_j4kBn*4GX>rFrCM zaNs6x0>+@{kMs%zs1TQ-A*HOzufy{R+6dnIRvl4>1i0l;iT$_tYhVX;~>0y?8nHOyQDk> zjUbfC8h5GB`rEAe4%>u>4CxKqcp!(?7YiocLcxsUBc?b4-pTW8vHKUA9_vB=T5g7H;e*@E(n@(ez^$pBgi zDvDezB87^i>K8(lc~e(f-tgFn<=pvA9=XEEgcg>nS5jCW+|NxNa`>fM!Nig>B3@zP zBqm-~Z;9Vy6xgG%VnoQz$D=7_FK0yV-$+%)let2fHE`+WZs1PH~@QVy?%ge*wGVwE$?hg9q+H)MP1XKH%-HxeDfLuN!GFE-Qn z;>5OsfxQ~C2!DC8%BfGkgpl4@_C-k*meZWAXHspZ&Ymi8i1cQUQMN8=(JO_grrC`ZwquB#0Je7x5U!VQzEWm6t+x$|^ z*W)v#FXt^_h9Ct}A7$e4=pm_uo*i20{xKEne}X;b{nTwN2AAEUSG3dY?Tvj*2H;02ft_m!I@5OkiVorwN9 zJa=OKp}(7mxXcG8?x&mky4TaxvI;l((tQxd2WG#0R=rCf6^eHxj2-#9JJyRy53foj zF<%6;sd7us5Z|PYzKk6ct?+U2bXiz$uBv}JEH+;9PqNzel+ba6P>gb`MPh|{11ZGtue{{vIHmUw$sdjRMfM|fD?b=GRcXdY!6$D)ph$R+~ zh+W#Ay&TNpBq37cQ#oY2w6XE&6O!$F9NTy4H^EB(?Ef*km88LyQQ(rJ>Q!%QBQl>; zKI$@eH`@(iwR_~-{+O2Y{owNcaI~?6zst#l*S*&eWcC|xp_+E6t@TgGmFOA^H1p#w zViLq!ofkTlSelb;<%4qT48umv3&DYm{$f|UC}hKW{|2?HlS&yTQiq>Ka${O`)!Ty2 zgbspU;~~JJ*mLElAy&$B7>V*CRhjMiPJ)&4U92EJ)Cq02(xakxo&NS~%ZbtFPvp#2 z`TLNwFC=}o2lX3{-B7xtT`EAM=dVjb<8j(PPW4N>9w=1ORYcS!dA9{7+=TB82gw`N zt1)qOw|tLB7a9)77+~fRk~{q|Nz6W<#~p(W=^@B~EtZ(#d`;g;(S_z1w55Vh0<+Q~m=}vbibcMH?#R z2T7?XJv03Eys$~cVXf)O^1gUfu<;cLT4VuObV((9Vtsvat$ljW^NFvBxX9Bsi{Y(E zq*bmKxBmP*w~mghHGkRiPKez>2uA?h^0GvzLnn{hU$!8UIJBk_C_LACFf$K54L1IR1 z(>YZf&|APjrp`FRqM4B>pYVVK7=f-#s(RKmf|oKHStsD`VtbI9;YNw4CHDRFs979;CF#TDf=+YPV)# z(**d2Pk&@d%#d?RN{&8l#M0!ruyylQZv;upIt?^Gun)WPO*ftJ&N2K_cK!q$}O6F8(^pKkk#Ih4ua``*bM5R&NkqXt#`tXrYpT-y-<4#fE+M;gE&09 z@|#aGez7?P{En%V|M*L9%IL}Sh}kWV$>)1P7H#ZSZ947QGo0TGEy{+OSGX>2)gW6h3aBLm%}jE)J$mf0eA3 z;xDI*I=svbW0Kcl9_Z&1EAY>`m>Sr(seTBuKNCy*Gs~^`Yy7ni%hK$pBjpP5g7c%p zXo{Hrprs-^BFJnV(Dy%AA5uj9IHZ2FtJK=cs+MVC!mcpLm=uCuMbARp_p_&%&y?$7 zc7(0J7jU?ov5?#9Zj;B2P{TIA4KuGIMlO*-ftTBu`x|$(;n8bT5r? z;_Y9BMd@;G$xajfTx z(cqJPr=Ia5bc8@k~Q_Yk}Oj>IDgXj0#YcDsLhA0 zad1{i(J^4*6*b8&u6{yN$fd36SbSv^ri)@C#~bK*`gWo!nf#q@9NK3Fg?pAyRXlQBIq8DVuUxsxLRx#Pu07;K3i5C_ zCLJw#V2c{0jfvxD^7>53Fq#t zchi|1P0XN|YaAUAYsJ031q09C;PLfUYX^av!?o<^GCi$y~`@qRw*>#0(x%}qyh`>(9X>bJ0 zQ%7H#D|wRiYVZMPocw+txm`Z_gukKVJ9if%$UyT3$#3kHYK#*8ka!H1b-; zZ3}bHy?pU0R+Uv5x0@?)2%^7)&0C&#jj)nq^er0qnWIzn+&ln3z@wRF*GS7JI=j7EYWNZ=s| z%u{^%DPjsRZ;US-cx?Y#O3%_bEby8C(MPc2kHEK!4=ya+pY7_h9|`)X+16{ihiW)@ z8N#?fG@y~ogg3NHSEN_Y1oAySn6;twT54|h&PA%0+H51VZA9b`7cF}0c56b^kP`a` z9`y_aDP2RnB%b=U>Za&{)tD=B$nt4xA_g+T>?oNYb(|i~6@EzL_bTw%ZqG_RJ+R;a zjtYW?t^z|)_Vf2YU9C(-A{ja?aS_o$#$*MZ3oHSj`_|%nO!r#TPWFF=>V(_z5J7=E z3NFyCej72_tlF8z`lP6|ADIJ(h=^cg%7X5YI+sn|bR)@=iSQ=?3>q7O{CE;FGb33d zRwuVML*wSWkKatznu`g)tSEDXZ7go_-_TytPxI#>sKWrLLukGS=`@T1#{!v>5^$8E zZ{Im4DrRdl1RMX{-`=d>aQH#X(WSF5YzE)|M=-;7%RsUF zyD|E;1q=wjsvj{rS@*vPiPG$ujFbZ-Dgs8d^Ipy?M@m1Z5}p#VMSI82X-@> zu^sQq$yAA|(}cJzUv$G0+^v?^OAoKc$nRnJdxmYTqZnm(I{Jz_|0O-hrP=ESUkxQb zj7n=*UtTIb^w5~?&n^lND^N=F`2#%QqC1lFbh=PxJ`Ln=F@WQoN14_tbeZ7HJ4oOo zG+n!LjyJ&r?Fu9A_j~#VtWOq6O~qj7-U0r1UAv zX+wiRYu(1mR-x>%+Q=Lb;2v;TX=l)Ba$d_TxrJ?1p+`T~-Ksacatmb-j>75Y=Z$-N zt%Wv5-Xq{2xb&F=Hs*8>1jKyYC!ALo6TftGyp#h4C{=pNyv+*9p!~*g44@CKQGW zKG8o5HU8H5oA{WGs{;GS);ZwR#b=eKBBm``rcXkdd|KN$l$2V7--L~JiDv0A#6-=+ z+wLs6%&kmJSoETPt|73sJM%0jjfW)mFvR#$t3^eIKB~@ecuNj95{LF&^P-gWn_Uz( zJu;*|%kYpD1ka%$BFS2L=)Ae!R4nVG$l)=zF|wIeroFEwm7)QR_9?6&VGYIAho~u7 zC}+%Cb?e-z!5CZdm*OUl6E*9$m@tDRG&KuoiQQn+z0Ia}r2JufwCSnG)fjMy_X-0J zcWg_qo}EuZn?%i}GhM*J>1=(N7aCf#ZlaNbgVd9F2dK&ysyZx?recx(LJ{g-vZZ{1oiEw5_OL|LG;`-Zvf1({3Hj@E<;F{+*oYou50t zNt9kY+sO^S(}r1@nfJelnR?HYnsRIQI@;%hFvA=~&~Z2Osh8Yf$gs8JY^ekrk_wt=X_(Og`mr$D%H0*o3j}JzmmpkbA_< z6B8}xdHNkU<=TyV$Q?O9pk(T|oWM4aQ4->5ypX_I@3&G-xA+i5EnDCmIj|;lPHlY( zZrfd7gwYUi-YjBuX@WEQ&Rm}W) zpYNS3t8+_S8kr&NSs?Cy)SR4NsGcT4c~%X8IV(UlGifcjCbQJ@#e9#*wf8HsfK{~n z_fO+Eth7Y+KuO;7PHIXv7e~a};6PTI*UpZxFsTmZ2Sn|_v$0SGj zyAu=pq^{PzBqx@c5un7gk#WK698jC$omhCUv0b9}<<_;?6JPQeK5n0&DXx;e_t zd~3H1A$vM8F#*KH*<&ii1hZb2Ou201GZzB^T>)}$AvehZi5e}!7Nv0aXK}<_?6eN z!u@8_xTKJXq*RT?vuADVKcCAbX=W8xe`*%J8iU9ZHqGtT%W(y1b@je$sjF~;N|Aks zORgS(1KWeyrR0GuR6%VkILeUWS&%dO*J$`S&PRkqtd1~*^V@SVsd6ZCa4LDIN2zIC zX>D6oMHK0&%nd9VaR8?>5b7zGpwc?CVZcinKALE0m^h@uLqjjf@m#h6jqg;UL`zf4Jas6PF(-}`&-8E-pdEnYh`a_f+ESQV0_uC^=zq5mP~K=T(E0U zUng^Vyb9fBP+!c^qH={n7cJ?M@2wb(+#Q3S@^NQ)xoxSoU3}+`c7~X^DNjOjBuL8} z@y4ZAE;C@SYhK*E7=_ARmeYoF#YldO6O`tSV1mwpXcx@WN#TYU@OKA%aM>N9(zE_aX~6yFKduW z%oLb&ZY7_`=X0Oi-+k16Pa9+OM1mGwmk|ewKCi)k*vdQdu+^YemBK()3+j3ll5RXi zhWZb;YjJLM3``g`wbZxs$vN6N5+%!W><|=K4){0JJ)GHDZg_w3pObIH1wR_zt~fjcFRKXZ0kYJit zzoN5~#^)7WlVU^;h=WLr?+2>oqT*4fymjc7nVl=}ZV&~CLJi*rtlMI_JxNAGE(6X3 z0qc^x#h&P1P_MJ6h$SwX8&RV2-u(xY>czeB)b_vTE$2+17R{7s&iT8(!vPm|`zG*w ziQD>$a$G`(^Tav1o2RzCI2HrNtAOq+HgGw%ed|_pC(Z5Mw^8yb{jPc= z8DM{lAWAaSD3<}1Tv$xc`|Dn6RMEvdppbomWm2Va2-IE2^J}zgBz*U?LD&g>Vg&XS?F~a4h7Gs zOzp3-EN%f+`H|1S!T#XRSYo{po2@1lM~+u^AP?Bh6I;<-jjZhQM`p5kYM>Ap_;WAS zkgqpP`AG<2fkFHu-42jiwd;x{^bnG_Mp2-v=OPS`vIhFc%+catCLef00cPg%Zgbgm z{zKTP9k7<`U*j_)FKRC_`hl{PSuK!AO8)3q2@O?4y(iCP@WCWhKnFIZJ7u1x?ffiw zh+s$#uYihkRBSrv<5U)6v+eO=7L*4vp%Ix#Z%`dCw;adIvbpJr6(6F%QB7wdS z*iyk1Ws1Nz~nsd{1t?Bq9t9J1wKTBe#(P&UlL6y@!06e-^Wt?Tg7pm;+ z8LWMD4-6bW<9e1;zkIrY@Iz^{$Q~Wb{Acm%nrcJaYu~ zu=L?95us1H_q6^4|Y(Bk;%GaFC;P8SA4<(3B}dog3hp7<6CA0UbWiF@9wf&s^0 zoiHI0wKPy!#fRu-`4JbnQ9JRQ-vtS*2LeslJ<9F!N@WOVckv=T!zUSb(-Qes>9EgX z1nIs|bb&yk_K-_GT=|wfV>k%rK^fVM7}(s&Ah&D%LaTYGy+5ctfQ7|qLG&3nU?a*v zlX2y+9;oXk5YMqdQ@^(gTQNOB|Ad-@E>CGawq?5A$e)lqLSn?A_NPA= zK^6#r;07?*!HX|5cH$LR3}o<`1|)V73`D{$TX85)nRahru&mkuF1X#sy7fwj3^lp_ z@&St6RVH_S>vs&mVtFFQ#PBP#!tpskPNFq2I-FB`l#y^0e*owj&KPhkGZf9xb@o&u zs1J``M&sIP+Vv8Oc;SWM^CE}AO|{>L8w%WUd~fj8k=qi0oM@Th4kEW8p81*;{%}$l z-yr#Idj?&YXsvL=l(BrpfS{$hYXNy(Xb6)S)+z3MX}cgjXQzQ5)A5Z>Ok zKuB<_7l$%Q(|+(!r?5sAHzuDPJk27zi zF}D+G>2s-HwEz=^5-tiH|iTFTqz4hHxy;HLN^%%9k z0!Q3+x&0boNF~MqK~P=bAWV{#djd>ORKSB5*GVUsY{1m28S>gBEjFb6X?W<_zpE&^ z+`b`VyHzlb(Yf|_+YX_#flUjbw*`No@a7FC!L2Nkr{BCJVWCzn!VVjqcqkL|7Zm{Z z1rq5OcKbLESIktOAy7PKlQetlUW-)BzX5BBxtQ@6Y3wa-kX+)mP_y(e*5pdPL_q)5 z$l1Ubj|zLdOopTWYM)G*j9$$c^jMQDpUAQkv_FJj;;GuhrTnaTmVbvagJHMJmp?32 zBY0yvqhI3>L}MVUq}fk5B%;)WQVS0qP#$PeoDUPc@|U31d`&RU-(c9sU;h_! zod2ht=+*b7GGHj$VSXU-hlZHiiHN_QRmE^c{taEAJOFm*70QJ$hbFwKUGs0g6`TV= z1jR54T=<|-I+(}Zg2w}hA!s(xf&aow5F#kJ>{Ck9f^rqmZIgmaV}*Wh*IqqcG-oLR z?I1C*>bPOnBnXpLvZvQyUm(bjK!Eqck*yaX5Tr#Ag4h)>(x6-htSu8`jz8;xk%}&j zh(R0iv3zg_q6iTJz3&YYd)0q&hd*MJfIARF6ksSDo_f(&K2_P$rG+pwY-5u@ZudVO>@x z8~MzgVPo-9S1L(mfuL>(P@n_X)O zN1)6yItu%EhSbZXQV&TTGfm;A(x~U0z;nCy5!UT}0p>IZb-Ory!(x*rNGia+*-<7hzy@f%)_OJh#(L3LaUldfp8cv1P9u zzsfwB0i3)x)Tnq}^0zll7(NVrY36v~R{N-vPKmFR`Re4Hm!r+v#8@x-Yf|lGl;!CD z^vGE6c{4v_?{msoTZt9g$#o&|^F1D8mwQ)Rr$dW)&O!DdjL_>m%VBWvEvjXBjy8P( zff{-bLxW`8e3h@Ir=U+5TUGB~_S_WZl zYN6q?G`$$wH?3aZDWLP9i9KxB)HW`dOxQ`i{k!tO2T+eb3D_ zyTps6kRz(WdCsvOe@t(ZD57nq0sFV-YQ+lNvg}f0MXy5TL>I{T(dM{Bfer#H<`D? zOn#Lo54s7z&X+32Ypd9mx98r3x6+Q&Qf}0B`x-+$uU*a= zOndp?EF{IZdGF0$2@g6wvG(6=B3Wa&#vP{Yv{*DfW65GPNTe^7mmMFnsFSrKe=;-D za9r7MNls#>6XbJl(ND%_?Z{g0a38%tiS{t|hzszA8sSA1+GRJWLQl6mPH?YCc012U z(CGOz>YT0$2W*ozROuStTWX72Qs1|OV798pL~>iBy{FTs+r8pjZ6r`0Z|xg^P8IGba4vhbN6T*_yXGY z>u@rr34Z+(^@gMD9jV{T!IQoNm#-i3L0T;|KuEM*t|7GJ6+R6`_Z7G-BOaePw=^+0 zH->#TFCOte4S@NM=_M`lb;AfBh+q4uw zUvbLZsH%75P~q3NZl#S^AH7dj+Orzge>>F5@BAU3@WYX3#&T)FU~N+pyOBx_`_=*L z34O$ss2Sq44w~>68^oO@>;f>w<`9*UgVxY4-9bsywe9nystNW7n&b*h`oMp~-!j6i zy~c}&;NJJ3YEPcgmO`nW&C-DVw6$8B=}Q0oET?xqG8?U@bLv=oa+c>DYtMtpW=Z#z znD>7u)#L7^9ZxKre&;`4G$!}keuX~Op`v3OqrVt20zdb{03NwuZakcpgSeGX)Mz#R zuYO!^)z5hD|GC>6G@R;n&>OJD>Ay`9ut;*MadK3tRKLj|zmb&cFj}4biY2xF)S8&* zB&xE(@3h|UbT;jH8noGuiUW2r=`+&A<0GwS;g81*;E&uohU&A~qJ&#Za?m==F<# z?X$1MTsSkqgON^jzDIt?`t;U%ok#uFCvZyu#eZ_A#L&dQQ8s9|4VUYthJEKX-{^5l zzOWr$T3ULzyUN7CfJ~D+JZ#w29M`DCoR7kI7^9v2+IDJF(J4~ZbrI@&F+{w7fcOkZ zYZ74A`-y5QHk53r`hf1pxv=8KW>rC zxaI54yW3q8mq?6@j)>^$>e4{^&*Y}@pGz;G-4nZj!`*@Jr!O zl1n0%wbrw(k3Ky@sP(2r*U=K&TxnsbHq6S_`#{4-iduwUR~_QeaRoN5^%1 zt2`E@pu`qsg3+hl0oB-7XckQl`+Q$hn|$8Q$ zKE2$s>zjUwgqy_SbUNx)!dHD0$<3c9IXC#FLV1ShklzDVCv;=WsQBQ`V;OG}1n0Z< z7a{~X1dvw8b66P!28G?_8%$xzPUweQ#`C&M^0@D7T!a{2{||V$E-|%D{cO6)rWheK z=jybbN*hCG>YXjBXC&yj*OrBLY390V6C!e-r@V^xDB0DTsZC3TLC}158^h03bI1fb zDUL;DLn>E0FNj}zvHl!{pxcqN6ns2Z?A#fVg0LK15tXId&+H@x8_P3n{k9b*l1o2+ zq*zN}nj4&3DU-EGrIl^8;0nu;t-pT#y8FG1N-#%Ae9rB-<<6@TH!~YS?@tlxCrv~b z@F#K%e{*X?Ha4`gD{dLp?zr*P2Eh@Y3#CNk5yk07@J;y8Twa9W3raq!vx;_titJl# z`Tg;fTILb`0X}#9=SD{w>c&_7u%6$6=no{rrkZ4 zkPjIxk3e{4IWFaB<1@OeMqN3@PfCjF?7!S1FJl$3Z0FoYN4YN@{4$8>6`bC5n?onZ z(jvq_NY;N{15JL!x>)0%g>kPb7;uk#{FpefyBTSI;$ie2hGThTimQev43!fROV7oBY<%fwTEI=>sIe`g-=D(hXso2jXr@G^AZwoF!!EG~ zMy1!EC&n8VW71+uRMee6XWERY181~?41^*#Gs=cY8!8eU5j7SqYGx5Eyhj($q$iAe zEovNx25k4!`J-+02EXz9r7K)zmp@k6WMHx7pE5HtP_}fY_^2?u=TR@>yoFMIb;h;t z)bv?g)yYei=kSJy$cFyXQ#pAxm)l?RHcXoMw` zEf!MD0~PrQ=9=SAEQf>bhHLs`+OW@Vg)`OtgYsMX&7LX>*;B8aD!6V^YHejjb)|WA zlfRrwOEsyz>(n~ef24e#qLJf2F#;`}?qf#rXRC+v%|R*@?|_;dcpR6iEO+FhNA);N zJuz(Z#|3Fe!-rD`CvMKcaK@W5l6JlBWmFmQ%%eV-RhENxX_oz9QdjnbkRJ@1M?npD zDfaw7&URB0zdCOg=S;ALNtHhHh^5QdA_VVHJj;l^Ikobc!ya39n68gd>RmLV2U9@^yp<~(M&{7;cw02^pK-E|3J zERPtHx)7ml9ueS@BcyK=Nh7?ZptclbNu3Zvl^)**`+P%(QGG6$n9bkpjDB(&Vg#9 zKiAr?o1`>!NN~j{8*g1|WPRM(5MsbvoPj@Jt3k6AlB&i%)kZx=Q6XpVu+sIKi?p7- zQ*?wo-Xv=3Z_BtIQf)-NB}xtz_5F|gqP6JKF1+i+`1~=-UH>KP;_*w<1N8=9`r_$= zKcYV5w|t;V<`)F;DWbg*{Nv(FGaHt#Q^=M%;tP-KCh5<iRmxu zn>brE+MqT?$XGfpFbZufM&3E zqLb_nl00DDul3#CPj6K+cHBUT2i4%#NJk~ucNoO6|uhx zl+;Fu_HA8yBcBWhswb#%$nE$=Pq+^=S)`|jD%9bAgFDmwwYFhKbuT*x$*Z=Dra0jk zM6DmVqsi|#XP0((gywZuf<_qeT==m`Dh&U*N8-PqOGm@cO2t6 zQ$>Z>=ip~UuKozYWHl>c(>~mBx346m--PFa8wA*WaJ1+5rayn4P+nzVpnP0?bs#}1 zf#1QczJtgmh|Gqv*x?Z5UB(CfTXn7rw>~roxR1J?F)+n=o)ZYil$m%309aN21uf4-9}l!!+reBP%!;W_iE7F*+r>Zw>0=aOGv_h~p;q~7ti@Y5vy z7>ti-RzW)SG5(+ld-}xzw=a+55E1?|kR9#2_vdsoD{b^6-I>o3_;JP{lK69SxK{mV zy$K^Dk(arEYrqf zag7XZIL3~-fu_QF$M00hfA8=#$@J9p`>nGhyZB=|MA!c0?QwJT>2oP$g@bgmn#sY6 z9zA>B$8yJVIM#QuN&e6&&F?sJ2GF;6BJdtQD^NtnBDePf*PvvF?6xXgKvnvn8^A=QO{XlC7UyKBW_6mu)_p=a0 z3Hl6B-nB^;h~m!50;reV!bz=qxWiGs(gibNH{g*~3p>pF8nAs)D^=pg+xRL4u>A`2W5(@qfKV@&EIybQ2MvTuGgcz8SGAhcn8W z%o#8Cw zG}BWfu7lCw7BiFwIvmjFV6aaEQFavt(AuM7H3{#4I%DntDQv$2viX-7 zo(Te3dHg3@0y|+|V2^)kE$W>K{0jPW&;bxrUlopuEv!|iyy zaQ$?`(vFwNdkJdfz;9#7?2l|P>xvZUY=QUkpv5%vRG{wjc)@hwP>r}D z&)60(GK>}lWM)?i-a>%z*B-JHt*1Ah)=N|zZLnUj$^x%TwR)`S+q!$iO!e8I^2e9_ zrgn`qZw%&)77X~zZYV5EhyJR$LJp1KjidHWZPcX2OO-Sa*aasf!jUOx0G$Avm@^W$sM8%0EBfAwJM9j-@= zQ^h7bGBB6B3JM5*pPx9?{%9$<I})%G5abqS9j1EJI|~ z?fpHrxO}TY9LkL&t>=n2dhXDqRLfaPy)!IBIOr*N>F0Mbea5K^iSs@A1Eyk-84<7u zv)V9lS>fpUZy(1>HW(7&>OY@1zWS^)M}NUKVKjqHdQ~x3ixRZ;rQ|*QTVOe@?^JAR zv~q7|Fl9aBQkO)|_m|G~>t=||)qvNl@)E6Y)h>-Yz{E{A&A?l(%7w|?;LXmEN(s8p zN?eoSHw(r=gTz&~Fs0*)_hsEX6kWZkJARcIiG+U8i=w7P|Z8jb{4x6BwySF1uiQ|%(MA6bF6)nu{0U9J{CxFu43^c-8H0239dQRR7b zOTE%iw9SSyQQcfm^{EHA+rWX*lcLZb?99D1aSi4486oPascR zt#Z`>vEg@~vY6MW#lfFVF|oqQ(EI1vxqVW{;dUCu{$$^35%nk~nnmbw3%m$1NSyOo(`I-CiwPSoR;w7X*OlpY5XCI1-LbQ4@k$*0?48Ds zt$;hTu_VOd$d8yURkP$jf z;^(zd12%J;Y{~Y;wN+Z*A5GY_MT!)98Nia)$`}g90X(22$%_rXMX`ham*>WlWc-WG zdiP(_3?N^zQczZo)5c6)D+zr%=8DwFN{D0!#gE^dI-@k4pm~V*JNEK}9rnL{P+I;^ zp4APj>)wp&={-4Jo%AaD@F=-$V?lCZ^|+wA`hlas;Y--l5YmgP(78KjuY9>}^pNtM zvtp+MZx(Oodvmd*_Zc0|y!ls$bGVSsyc83bPn#*9G-q5o|61V&W->McUnMcx8tkav6`SOvlSUVdQhO1HtH&%JUXw;~y(S3tAbC0oMni+DoUQ^PS$+!qLH1JQ0{GN-)Ydo@d!eB`K+p#yS2 zSE|x&G^e=lkG5c%a^`@0ij14vE&e3c{ci?#I?FU0cW60e)w&P`80?w#^#yHDqcSy_2&OZ4dv zqJvX2x2Zj4RsQ*Ust@*bWug8dcfwhyC}ebKw;*T@gwI4@w6lAC53u~6`>F#=tq!!y zg)3QZ@XML@dOq3t`R<1mNrgt$)4}926377v>Y~F(Uvb_obJ9Zvk5_ZQNEtV!HFh!l z61RK)9aCV4@*X_n&j1C2mvf+J+6+U53Dl;T;RX@I%NkQFLDo+2Kqn&Tc?UiyQs=&K z#?+Yl!6OuIr}A>-!sk2pN)=#&<5?G=ck1}*Cgq(T3ln>LdmDus`-#-DAB2QI)ZNk4 z)b#N=jDJ836^#I_`S@V)JZY$MJfr{itQO@Xozbf`VyMR$J;(CauQ^(Rt@P=NgY*`; z{8!Ukzdo|ayY|Q~LR3+=;}b*54;BUkO!^C3i(ouUu!||7XpwKY@g80Bpy<_mw`MuygEy$eD4)RuLK~yVcOuD{1q#fJ9=vo@J&b*X=>amo^y};p zN8b6N^NRVRFGODm8Z*7;sr3uqnz_%(Jk>8Fh3|M-RfidxIevLkjjX%6@7(=`(-{INquM@BZ6UiA>uUY8~d{VoG>+DETJO&Nh!Q|4LhK>C?k+E0!TYa2O&ZPH*iq_@kj z(0jjDD<=;!4bdZr_0t;WJ)WH>tAiUK%L9%@{l?LA_M5Tc{3f+l-G}mfpEv`KODp}> zXH=7Rsv1eAq|=8y?S5S|?n`BCPx>N|P5zn$GMF6!;pKbX?_#7mai>aOYa_6J%SrNw z%bdMFe=>OrtELxECK>#FJ^bwVtW3wVBHaDd&T$ zB{_ef!miI7+~VTKa9lm-(BAR&rVugo;W~aFU#?YH*yTy;0tNeSV@`i}%&GEE_MzpA zycd%CTRt6}=eJAqoP>9CbZwrP<{i#8T-jY?q^CD1wQ~2s^?&yRUDaZ8wJTvQu{`nL z%(-~uzuo2HP5l0B)6GwO{!cs+B;53j9T@jcN=f!LO8&kQC6oK85bp(l_tOQV?3>`0 zy4A-*kICQZmq{dfjB7CW4{HB}V##xu541d{IoX2p^2VnI2M5veKWja3(QEr1JdVCT zW}>>6^WG>%hKXJ~tA{^a)?~o@h!h^ke#sRj!J@o(rgCv7>rcIDY~VD*)SPO3kX zTrJvII4#&wZi655Fvy49EIjIra)>Vif>P6U;!~&FwWi~U9lmxqZh>oWY$M?5tPR2B=mXeZXi-~rhXefn}foyukC`8>!pZpYcaOUkpY!@;h}=6{~5J^DeZ zl|JPavr)WZ9B@;4*i~u7RQbfy^v)Mk9-kjqwb)>6>FFpGDuIiddwOTl%;^)op2aKp zOdh2Z_vE_;Y7$5d+y{f+>mRQ?eY9ipS!pVl+R69I`7brquTCdp%#X(-NlDJ1w<8~X zC*Vd+O`YLVEp(ua@}%6D6X;4(c_COK)!vkI5dUl5y0nh!Uu3X#-(vjbgRP^dT&NSA zMrDrIv_@}xQ_^4uk8s!b7YnHZP~}%p9*?=V(}Sb0C@AE7j~BUiFx!%AYnjgxqpNCN zZ%}agQHdgP`Z5pG*E%Mss0yFIi)6n!X4F;xc5QGW)uX2pXP;+uXjir!>u+v7-IK=A zsiAN~z-3EHOEgDOfdPjsIDETSz7XH}1G8;>?mY1j3LDu(>ol+~*<+fYx{%4FDj7EwsDA>i|R$>Qrkc(U0 zn|>0=tPh{<>j<~fQ}bozv^R24i(MU2`1a*YN?GeQ*IgQ?;yXFFWauB!h@Nh!t@oL7 z=+3?=FYp#ffFr&pGD_(epxyfHzCSRcuW_MQDWAV>4+RQ?n|A<-^5@MWC}W<<2R}8V zN)S|ie?jExyWIjB!-9aU;)~gi6MC1)58B(}aI2+-rZb=4-z!VLC*qb(dsfV34_?UO z=Gbq#_)P%30Y^r<0orF8f9>cBL)o{8x$ySJOe(SDqW0J7XT_eVe|w*L*|1`2eNDH( zIL8q6K-csk3iD@sGa_lRec>Onggff6&BHc-ilLx4Uw>272)Ny{z1>X&^;{wNP%W1b zTe2J}Py0LrZcbwA;|xGqp#Am5GpnP|*P<#XQJeS22MuT_MYZH4;38Px8|A!gpRdX8 zPuymwp_DyZp$^8$KI$a<|Ju3IuO_Z2J}xcx0D_{JQ)DR?fr1bVhAk3=5K)#^79$Z^ z$|^Ag2@*g82$i*nm|_YBDWw65l2WN!0ue2WWgP(#2}@G8C<+l`5=kKG3#VWEAM|~i zGv~~mdH3D-=6CP?-CJgX!S1LSWoS6965@867&L0XYUV>+OZ?Ek(3l2JNx|r`iRs)n(;C>zgf|JWb8VN?%;Sbr z<#&o2NpA?}mu^kXGK~#C-D|keTWYB3oo4X!m!vbTtXMO<1A|_5dv=RmwQ4`}{fS`1 zc>a)Sp!Syd1dV*M8bf*dbw=!ozXF~h{~7Ik9Y8yTXVrzXpK>vqO}p;_NpP=uG@ zuz^X2-gYE!CgWL}kQNw`X!9M;vI$K+y55yIQ2Z@>iEec$j~8baanl~MPT!E&g&>mN z(^b5iX0o+8-^`)kx7a>#u54J!Tr}-K^)#?cWc13zvSw*~6OG6_epjG2tS6wT0e~V- zR4LA?ym!vLI>W!w6RJXA@hUYq8HoAAfoY#f$& z(oGK{@m6(Ffuk^L1w9`Zie2BGMf?02=W;Mn^6gCh!N({7KvC-N^B>fD9rwHc_gm|B zHMP$&i*1&PqjGJJ@`cj9F7mjZk9QeE;bj1iyNQzk%Sa=rBwkap!@cn%4I%UHJy*0B zD80(O{%2u~wf%E_zvtmb1A8E(-iBb7zhyN{O-aF>tx1Uv^VU4k((qQmEp613EaYOj z0o|WGb+FJcret&h)C=NMZgly&9lTvfhnk!m)iP!Q*<%Z4anjsO;cc@hgt^-pFk$2(_DBiNxWJZffx`z1&%?1dSQDIEosAYGwYbNEK zdF8FdwZMG3{Z+lbGTkzhZ8n^DIlRuK)(pYJn%w;K;F{f#zBvvA?Cj!6XVXL%m8nlw zqP1aoGDu-*wCdnOr7ib{vG#6)igm%hiNoFJ&ds-+l=e+7*H^iP-nrl%7N%O~D<8d; zYCuSedVQR4IFMhaE3c0^^KLUN+36!zDq&6jQ5-H-)(loeeOOXXjGQK?(R6*pd{r7^ z0JL>sbLWG?6fkIhk_$n@Af}u>e}^{Siz0<&6_xCX=XI9jL!|4*u8#J}$yZzrA*8nY zRe*3hA*;x-#Nusard@SyV!f#AmyAW1Dhxa};&BJv^-4`!s} zu4`p&v2TE`&#K*BF~54^!bQ`vZ8;|8$NQ%vgdG3Dp`kBPsFc5@46>8xNypggxYN2d zRUt8>ImrA%UQ2rg6?C!fylTl#ZJV+1Qx0|(|p-6)jZ8hLuWO`oF!t|ae=FNRY3gDQM@PO;ww zH@p*+Qm%DHAm+uZ4fl-|k1>m5;=Xo?9)vVI(;6>!mu-TOLR7*jl~Tqf0uRx%V;at_ zfOEEWCXTYrF@REwS$PG=vb>?}3U!1RR2Vtr6U86_3#Cr|djlXyFm%<29w5=HQ%8Wu zhz8RHNzYWEN-&lI9tUF@Yu4!_~%e%+n9c Ib`Q__2b&h+`Tzg` literal 0 HcmV?d00001 diff --git a/docs/configuration/nat/index.rst b/docs/configuration/nat/index.rst index f0f5bd6a..90275226 100644 --- a/docs/configuration/nat/index.rst +++ b/docs/configuration/nat/index.rst @@ -8,732 +8,5 @@ NAT :maxdepth: 1 :includehidden: - nptv6 - -:abbr:`NAT (Network Address Translation)` is a common method of -remapping one IP address space into another by modifying network address -information in the IP header of packets while they are in transit across -a traffic routing device. The technique was originally used as a -shortcut to avoid the need to readdress every host when a network was -moved. It has become a popular and essential tool in conserving global -address space in the face of IPv4 address exhaustion. One -Internet-routable IP address of a NAT gateway can be used for an entire -private network. - -IP masquerading is a technique that hides an entire IP address space, -usually consisting of private IP addresses, behind a single IP address -in another, usually public address space. The hidden addresses are -changed into a single (public) IP address as the source address of the -outgoing IP packets so they appear as originating not from the hidden -host but from the routing device itself. Because of the popularity of -this technique to conserve IPv4 address space, the term NAT has become -virtually synonymous with IP masquerading. - -As network address translation modifies the IP address information in -packets, NAT implementations may vary in their specific behavior in -various addressing cases and their effect on network traffic. The -specifics of NAT behavior are not commonly documented by vendors of -equipment containing NAT implementations. - -The computers on an internal network can use any of the addresses set -aside by the :abbr:`IANA (Internet Assigned Numbers Authority)` for -private addressing (see :rfc:`1918`). These reserved IP addresses are -not in use on the Internet, so an external machine will not directly -route to them. The following addresses are reserved for private use: - -* 10.0.0.0 to 10.255.255.255 (CIDR: 10.0.0.0/8) -* 172.16.0.0 to 172.31.255.255 (CIDR: 172.16.0.0/12) -* 192.168.0.0 to 192.168.255.255 (CIDR: 192.168.0.0/16) - - -If an ISP deploys a :abbr:`CGN (Carrier-grade NAT)`, and uses -:rfc:`1918` address space to number customer gateways, the risk of -address collision, and therefore routing failures, arises when the -customer network already uses an :rfc:`1918` address space. - -This prompted some ISPs to develop a policy within the :abbr:`ARIN -(American Registry for Internet Numbers)` to allocate new private -address space for CGNs, but ARIN deferred to the IETF before -implementing the policy indicating that the matter was not a typical -allocation issue but a reservation of addresses for technical purposes -(per :rfc:`2860`). - -IETF published :rfc:`6598`, detailing a shared address space for use in -ISP CGN deployments that can handle the same network prefixes occurring -both on inbound and outbound interfaces. ARIN returned address space to -the :abbr:`IANA (Internet Assigned Numbers Authority)` for this -allocation. - -The allocated address block is 100.64.0.0/10. - -Devices evaluating whether an IPv4 address is public must be updated to -recognize the new address space. Allocating more private IPv4 address -space for NAT devices might prolong the transition to IPv6. - -Overview -======== - -Different NAT Types -------------------- - -.. _source-nat: - -SNAT -^^^^ - -:abbr:`SNAT (Source Network Address Translation)` is the most common -form of :abbr:`NAT (Network Address Translation)` and is typically -referred to simply as NAT. To be more correct, what most people refer -to as :abbr:`NAT (Network Address Translation)` is actually the process -of :abbr:`PAT (Port Address Translation)`, or NAT overload. SNAT is -typically used by internal users/private hosts to access the Internet -- the source address is translated and thus kept private. - -.. _destination-nat: - -DNAT -^^^^ - -:abbr:`DNAT (Destination Network Address Translation)` changes the -destination address of packets passing through the router, while -:ref:`source-nat` changes the source address of packets. DNAT is -typically used when an external (public) host needs to initiate a -session with an internal (private) host. A customer needs to access a -private service behind the routers public IP. A connection is -established with the routers public IP address on a well known port and -thus all traffic for this port is rewritten to address the internal -(private) host. - -.. _bidirectional-nat: - -Bidirectional NAT -^^^^^^^^^^^^^^^^^ - -This is a common scenario where both :ref:`source-nat` and -:ref:`destination-nat` are configured at the same time. It's commonly -used then internal (private) hosts need to establish a connection with -external resources and external systems need to access internal -(private) resources. - -NAT, Routing, Firewall Interaction ----------------------------------- - -There is a very nice picture/explanation in the Vyatta documentation -which should be rewritten here. - -NAT Ruleset ------------ - -:abbr:`NAT (Network Address Translation)` is configured entirely on a -series of so called `rules`. Rules are numbered and evaluated by the -underlying OS in numerical order! The rule numbers can be changes by -utilizing the :cfgcmd:`rename` and :cfgcmd:`copy` commands. - -.. note:: Changes to the NAT system only affect newly established - connections. Already established connections are not affected. - -.. hint:: When designing your NAT ruleset leave some space between - consecutive rules for later extension. Your ruleset could start with - numbers 10, 20, 30. You thus can later extend the ruleset and place - new rules between existing ones. - -Rules will be created for both :ref:`source-nat` and -:ref:`destination-nat`. - -For :ref:`bidirectional-nat` a rule for both :ref:`source-nat` and -:ref:`destination-nat` needs to be created. - -.. _traffic-filters: - -Traffic Filters ---------------- - -Traffic Filters are used to control which packets will have the defined -NAT rules applied. Five different filters can be applied within a NAT -rule. - -* **outbound-interface** - applicable only to :ref:`source-nat`. It - configures the interface which is used for the outside traffic that - this translation rule applies to. - - Example: - - .. code-block:: none - - set nat source rule 20 outbound-interface eth0 - -* **inbound-interface** - applicable only to :ref:`destination-nat`. It - configures the interface which is used for the inside traffic the - translation rule applies to. - - Example: - - .. code-block:: none - - set nat destination rule 20 inbound-interface eth1 - -* **protocol** - specify which types of protocols this translation rule - applies to. Only packets matching the specified protocol are NATed. - By default this applies to `all` protocols. - - Example: - - * Set SNAT rule 20 to only NAT TCP and UDP packets - * Set DNAT rule 20 to only NAT UDP packets - - .. code-block:: none - - set nat source rule 20 protocol tcp_udp - set nat destination rule 20 protocol udp - -* **source** - specifies which packets the NAT translation rule applies - to based on the packets source IP address and/or source port. Only - matching packets are considered for NAT. - - Example: - - * Set SNAT rule 20 to only NAT packets arriving from the 192.0.2.0/24 - network - * Set SNAT rule 30 to only NAT packets arriving from the 203.0.113.0/24 - network with a source port of 80 and 443 - - .. code-block:: none - - set nat source rule 20 source address 192.0.2.0/24 - set nat source rule 30 source address 203.0.113.0/24 - set nat source rule 30 source port 80,443 - - -* **destination** - specify which packets the translation will be - applied to, only based on the destination address and/or port number - configured. - - .. note:: If no destination is specified the rule will match on any - destination address and port. - - Example: - - * Configure SNAT rule (40) to only NAT packets with a destination - address of 192.0.2.1. - - .. code-block:: none - - set nat source rule 40 destination address 192.0.2.1 - - -Address Conversion ------------------- - -Every NAT rule has a translation command defined. The address defined -for the translation is the address used when the address information in -a packet is replaced. - -Source Address -^^^^^^^^^^^^^^ - -For :ref:`source-nat` rules the packets source address will be replaced -with the address specified in the translation command. A port -translation can also be specified and is part of the translation -address. - -.. note:: The translation address must be set to one of the available - addresses on the configured `outbound-interface` or it must be set to - `masquerade` which will use the primary IP address of the - `outbound-interface` as its translation address. - -.. note:: When using NAT for a large number of host systems it - recommended that a minimum of 1 IP address is used to NAT every 256 - private host systems. This is due to the limit of 65,000 port numbers - available for unique translations and a reserving an average of - 200-300 sessions per host system. - -Example: - -* Define a discrete source IP address of 100.64.0.1 for SNAT rule 20 -* Use address `masquerade` (the interfaces primary address) on rule 30 -* For a large amount of private machines behind the NAT your address - pool might to be bigger. Use any address in the range 100.64.0.10 - - 100.64.0.20 on SNAT rule 40 when doing the translation - - -.. code-block:: none - - set nat source rule 20 translation address 100.64.0.1 - set nat source rule 30 translation address 'masquerade' - set nat source rule 40 translation address 100.64.0.10-100.64.0.20 - - -Destination Address -^^^^^^^^^^^^^^^^^^^ - -For :ref:`destination-nat` rules the packets destination address will be -replaced by the specified address in the `translation address` command. - -Example: - -* DNAT rule 10 replaces the destination address of an inbound packet - with 192.0.2.10 - -.. code-block:: none - - set nat destination rule 10 translation address 192.0.2.10 - - -Configuration Examples -====================== - -To setup SNAT, we need to know: - -* The internal IP addresses we want to translate -* The outgoing interface to perform the translation on -* The external IP address to translate to - -In the example used for the Quick Start configuration above, we -demonstrate the following configuration: - -.. code-block:: none - - set nat source rule 100 outbound-interface 'eth0' - set nat source rule 100 source address '192.168.0.0/24' - set nat source rule 100 translation address 'masquerade' - -Which generates the following configuration: - -.. code-block:: none - - rule 100 { - outbound-interface eth0 - source { - address 192.168.0.0/24 - } - translation { - address masquerade - } - } - -In this example, we use **masquerade** as the translation address -instead of an IP address. The **masquerade** target is effectively an -alias to say "use whatever IP address is on the outgoing interface", -rather than a statically configured IP address. This is useful if you -use DHCP for your outgoing interface and do not know what the external -address will be. - -When using NAT for a large number of host systems it recommended that a -minimum of 1 IP address is used to NAT every 256 host systems. This is -due to the limit of 65,000 port numbers available for unique -translations and a reserving an average of 200-300 sessions per host -system. - -Example: For an ~8,000 host network a source NAT pool of 32 IP addresses -is recommended. - -A pool of addresses can be defined by using a hyphen between two IP -addresses: - -.. code-block:: none - - set nat source rule 100 translation address '203.0.113.32-203.0.113.63' - -.. _avoidng_leaky_nat: - -Avoiding "leaky" NAT --------------------- - -Linux netfilter will not NAT traffic marked as INVALID. This often -confuses people into thinking that Linux (or specifically VyOS) has a -broken NAT implementation because non-NATed traffic is seen leaving an -external interface. This is actually working as intended, and a packet -capture of the "leaky" traffic should reveal that the traffic is either -an additional TCP "RST", "FIN,ACK", or "RST,ACK" sent by client systems -after Linux netfilter considers the connection closed. The most common -is the additional TCP RST some host implementations send after -terminating a connection (which is implementation-specific). - -In other words, connection tracking has already observed the connection -be closed and has transition the flow to INVALID to prevent attacks from -attempting to reuse the connection. - -You can avoid the "leaky" behavior by using a firewall policy that drops -"invalid" state packets. - -Having control over the matching of INVALID state traffic, e.g. the -ability to selectively log, is an important troubleshooting tool for -observing broken protocol behavior. For this reason, VyOS does not -globally drop invalid state traffic, instead allowing the operator to -make the determination on how the traffic is handled. - -.. _hairpin_nat_reflection: - -Hairpin NAT/NAT Reflection --------------------------- - -A typical problem with using NAT and hosting public servers is the -ability for internal systems to reach an internal server using it's -external IP address. The solution to this is usually the use of -split-DNS to correctly point host systems to the internal address when -requests are made internally. Because many smaller networks lack DNS -infrastructure, a work-around is commonly deployed to facilitate the -traffic by NATing the request from internal hosts to the source address -of the internal interface on the firewall. - -This technique is commonly referred to as NAT Reflection or Hairpin NAT. - -Example: - -* Redirect Microsoft RDP traffic from the outside (WAN, external) world - via :ref:`destination-nat` in rule 100 to the internal, private host - 192.0.2.40. - -* Redirect Microsoft RDP traffic from the internal (LAN, private) - network via :ref:`destination-nat` in rule 110 to the internal, - private host 192.0.2.40. We also need a :ref:`source-nat` rule 110 for - the reverse path of the traffic. The internal network 192.0.2.0/24 is - reachable via interface `eth0.10`. - -.. code-block:: none - - set nat destination rule 100 description 'Regular destination NAT from external' - set nat destination rule 100 destination port '3389' - set nat destination rule 100 inbound-interface 'pppoe0' - set nat destination rule 100 protocol 'tcp' - set nat destination rule 100 translation address '192.0.2.40' - - set nat destination rule 110 description 'NAT Reflection: INSIDE' - set nat destination rule 110 destination port '3389' - set nat destination rule 110 inbound-interface 'eth0.10' - set nat destination rule 110 protocol 'tcp' - set nat destination rule 110 translation address '192.0.2.40' - - set nat source rule 110 description 'NAT Reflection: INSIDE' - set nat source rule 110 destination address '192.0.2.0/24' - set nat source rule 110 outbound-interface 'eth0.10' - set nat source rule 110 protocol 'tcp' - set nat source rule 110 source address '192.0.2.0/24' - set nat source rule 110 translation address 'masquerade' - -Which results in a configuration of: - -.. code-block:: none - - vyos@vyos# show nat - destination { - rule 100 { - description "Regular destination NAT from external" - destination { - port 3389 - } - inbound-interface pppoe0 - protocol tcp - translation { - address 192.0.2.40 - } - } - rule 110 { - description "NAT Reflection: INSIDE" - destination { - port 3389 - } - inbound-interface eth0.10 - protocol tcp - translation { - address 192.0.2.40 - } - } - } - source { - rule 110 { - description "NAT Reflection: INSIDE" - destination { - address 192.0.2.0/24 - } - outbound-interface eth0.10 - protocol tcp - source { - address 192.0.2.0/24 - } - translation { - address masquerade - } - } - } - - -Destination NAT ---------------- - -DNAT is typically referred to as a **Port Forward**. When using VyOS as -a NAT router and firewall, a common configuration task is to redirect -incoming traffic to a system behind the firewall. - -In this example, we will be using the example Quick Start configuration -above as a starting point. - -To setup a destination NAT rule we need to gather: - -* The interface traffic will be coming in on; -* The protocol and port we wish to forward; -* The IP address of the internal system we wish to forward traffic to. - -In our example, we will be forwarding web server traffic to an internal -web server on 192.168.0.100. HTTP traffic makes use of the TCP protocol -on port 80. For other common port numbers, see: -https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - -Our configuration commands would be: - -.. code-block:: none - - set nat destination rule 10 description 'Port Forward: HTTP to 192.168.0.100' - set nat destination rule 10 destination port '80' - set nat destination rule 10 inbound-interface 'eth0' - set nat destination rule 10 protocol 'tcp' - set nat destination rule 10 translation address '192.168.0.100' - -Which would generate the following NAT destination configuration: - -.. code-block:: none - - nat { - destination { - rule 10 { - description "Port Forward: HTTP to 192.168.0.100" - destination { - port 80 - } - inbound-interface eth0 - protocol tcp - translation { - address 192.168.0.100 - } - } - } - } - -.. note:: If forwarding traffic to a different port than it is arriving - on, you may also configure the translation port using - `set nat destination rule [n] translation port`. - -This establishes our Port Forward rule, but if we created a firewall -policy it will likely block the traffic. - -It is important to note that when creating firewall rules that the DNAT -translation occurs **before** traffic traverses the firewall. In other -words, the destination address has already been translated to -192.168.0.100. - -So in our firewall policy, we want to allow traffic coming in on the -outside interface, destined for TCP port 80 and the IP address of -192.168.0.100. - -.. code-block:: none - - set firewall name OUTSIDE-IN rule 20 action 'accept' - set firewall name OUTSIDE-IN rule 20 destination address '192.168.0.100' - set firewall name OUTSIDE-IN rule 20 destination port '80' - set firewall name OUTSIDE-IN rule 20 protocol 'tcp' - set firewall name OUTSIDE-IN rule 20 state new 'enable' - -This would generate the following configuration: - -.. code-block:: none - - rule 20 { - action accept - destination { - address 192.168.0.100 - port 80 - } - protocol tcp - state { - new enable - } - } - -.. note:: - - If you have configured the `INSIDE-OUT` policy, you will need to add - additional rules to permit inbound NAT traffic. - -1-to-1 NAT ----------- - -Another term often used for DNAT is **1-to-1 NAT**. For a 1-to-1 NAT -configuration, both DNAT and SNAT are used to NAT all traffic from an -external IP address to an internal IP address and vice-versa. - -Typically, a 1-to-1 NAT rule omits the destination port (all ports) and -replaces the protocol with either **all** or **ip**. - -Then a corresponding SNAT rule is created to NAT outgoing traffic for -the internal IP to a reserved external IP. This dedicates an external IP -address to an internal IP address and is useful for protocols which -don't have the notion of ports, such as GRE. - -Here's an extract of a simple 1-to-1 NAT configuration with one internal -and one external interface: - -.. code-block:: none - - set interfaces ethernet eth0 address '192.168.1.1/24' - set interfaces ethernet eth0 description 'Inside interface' - set interfaces ethernet eth1 address '192.0.2.30/24' - set interfaces ethernet eth1 description 'Outside interface' - set nat destination rule 2000 description '1-to-1 NAT example' - set nat destination rule 2000 destination address '192.0.2.30' - set nat destination rule 2000 inbound-interface 'eth1' - set nat destination rule 2000 translation address '192.168.1.10' - set nat source rule 2000 description '1-to-1 NAT example' - set nat source rule 2000 outbound-interface 'eth1' - set nat source rule 2000 source address '192.168.1.10' - set nat source rule 2000 translation address '192.0.2.30' - -Firewall rules are written as normal, using the internal IP address as -the source of outbound rules and the destination of inbound rules. - -NAT before VPN --------------- - -Some application service providers (ASPs) operate a VPN gateway to -provide access to their internal resources, and require that a -connecting organisation translate all traffic to the service provider -network to a source address provided by the ASP. - -Example Network -^^^^^^^^^^^^^^^ - -Here's one example of a network environment for an ASP. -The ASP requests that all connections from this company should come from -172.29.41.89 - an address that is assigned by the ASP and not in use at -the customer site. - -.. figure:: /_static/images/nat_before_vpn_topology.png - :scale: 100 % - :alt: NAT before VPN Topology - - NAT before VPN Topology - - -Configuration -^^^^^^^^^^^^^ - -The required configuration can be broken down into 4 major pieces: - -* A dummy interface for the provider-assigned IP; -* NAT (specifically, Source NAT); -* IPSec IKE and ESP Groups; -* IPSec VPN tunnels. - - -Dummy interface -""""""""""""""" - -The dummy interface allows us to have an equivalent of the Cisco IOS -Loopback interface - a router-internal interface we can use for IP -addresses the router must know about, but which are not actually -assigned to a real network. - -We only need a single step for this interface: - -.. code-block:: none - - set interfaces dummy dum0 address '172.29.41.89/32' - -NAT Configuration -""""""""""""""""" - -.. code-block:: none - - set nat source rule 110 description 'Internal to ASP' - set nat source rule 110 destination address '172.27.1.0/24' - set nat source rule 110 outbound-interface 'any' - set nat source rule 110 source address '192.168.43.0/24' - set nat source rule 110 translation address '172.29.41.89' - set nat source rule 120 description 'Internal to ASP' - set nat source rule 120 destination address '10.125.0.0/16' - set nat source rule 120 outbound-interface 'any' - set nat source rule 120 source address '192.168.43.0/24' - set nat source rule 120 translation address '172.29.41.89' - -IPSec IKE and ESP -""""""""""""""""" - -The ASP has documented their IPSec requirements: - -* IKE Phase: - - * aes256 Encryption - * sha256 Hashes - -* ESP Phase: - - * aes256 Encryption - * sha256 Hashes - * DH Group 14 - - -Additionally, we want to use VPNs only on our eth1 interface (the -external interface in the image above) - -.. code-block:: none - - set vpn ipsec ike-group my-ike ikev2-reauth 'no' - set vpn ipsec ike-group my-ike key-exchange 'ikev1' - set vpn ipsec ike-group my-ike lifetime '7800' - set vpn ipsec ike-group my-ike proposal 1 dh-group '14' - set vpn ipsec ike-group my-ike proposal 1 encryption 'aes256' - set vpn ipsec ike-group my-ike proposal 1 hash 'sha256' - - set vpn ipsec esp-group my-esp compression 'disable' - set vpn ipsec esp-group my-esp lifetime '3600' - set vpn ipsec esp-group my-esp mode 'tunnel' - set vpn ipsec esp-group my-esp pfs 'disable' - set vpn ipsec esp-group my-esp proposal 1 encryption 'aes256' - set vpn ipsec esp-group my-esp proposal 1 hash 'sha256' - - set vpn ipsec ipsec-interfaces interface 'eth1' - -IPSec VPN Tunnels -""""""""""""""""" - -We'll use the IKE and ESP groups created above for this VPN. Because we -need access to 2 different subnets on the far side, we will need two -different tunnels. If you changed the names of the ESP group and IKE -group in the previous step, make sure you use the correct names here -too. - -.. code-block:: none - - set vpn ipsec site-to-site peer 198.51.100.243 authentication mode 'pre-shared-secret' - set vpn ipsec site-to-site peer 198.51.100.243 authentication pre-shared-secret 'PASSWORD IS HERE' - set vpn ipsec site-to-site peer 198.51.100.243 connection-type 'initiate' - set vpn ipsec site-to-site peer 198.51.100.243 default-esp-group 'my-esp' - set vpn ipsec site-to-site peer 198.51.100.243 ike-group 'my-ike' - set vpn ipsec site-to-site peer 198.51.100.243 ikev2-reauth 'inherit' - set vpn ipsec site-to-site peer 198.51.100.243 local-address '203.0.113.46' - set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 local prefix '172.29.41.89/32' - set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 remote prefix '172.27.1.0/24' - set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 local prefix '172.29.41.89/32' - set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 remote prefix '10.125.0.0/16' - -Testing and Validation -"""""""""""""""""""""" - -If you've completed all the above steps you no doubt want to see if it's -all working. - -Start by checking for IPSec SAs (Security Associations) with: - -.. code-block:: none - - $ show vpn ipsec sa - - Peer ID / IP Local ID / IP - ------------ ------------- - 198.51.100.243 203.0.113.46 - - Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto - ------ ----- ------------- ------- ---- ----- ------ ------ ----- - 0 up 0.0/0.0 aes256 sha256 no 1647 3600 all - 1 up 0.0/0.0 aes256 sha256 no 865 3600 all - -That looks good - we defined 2 tunnels and they're both up and running. + nat44 + nat66 diff --git a/docs/configuration/nat/nat44.rst b/docs/configuration/nat/nat44.rst new file mode 100644 index 00000000..59cee741 --- /dev/null +++ b/docs/configuration/nat/nat44.rst @@ -0,0 +1,733 @@ +.. _nat44: + +##### +NAT44 +##### + +:abbr:`NAT (Network Address Translation)` is a common method of +remapping one IP address space into another by modifying network address +information in the IP header of packets while they are in transit across +a traffic routing device. The technique was originally used as a +shortcut to avoid the need to readdress every host when a network was +moved. It has become a popular and essential tool in conserving global +address space in the face of IPv4 address exhaustion. One +Internet-routable IP address of a NAT gateway can be used for an entire +private network. + +IP masquerading is a technique that hides an entire IP address space, +usually consisting of private IP addresses, behind a single IP address +in another, usually public address space. The hidden addresses are +changed into a single (public) IP address as the source address of the +outgoing IP packets so they appear as originating not from the hidden +host but from the routing device itself. Because of the popularity of +this technique to conserve IPv4 address space, the term NAT has become +virtually synonymous with IP masquerading. + +As network address translation modifies the IP address information in +packets, NAT implementations may vary in their specific behavior in +various addressing cases and their effect on network traffic. The +specifics of NAT behavior are not commonly documented by vendors of +equipment containing NAT implementations. + +The computers on an internal network can use any of the addresses set +aside by the :abbr:`IANA (Internet Assigned Numbers Authority)` for +private addressing (see :rfc:`1918`). These reserved IP addresses are +not in use on the Internet, so an external machine will not directly +route to them. The following addresses are reserved for private use: + +* 10.0.0.0 to 10.255.255.255 (CIDR: 10.0.0.0/8) +* 172.16.0.0 to 172.31.255.255 (CIDR: 172.16.0.0/12) +* 192.168.0.0 to 192.168.255.255 (CIDR: 192.168.0.0/16) + + +If an ISP deploys a :abbr:`CGN (Carrier-grade NAT)`, and uses +:rfc:`1918` address space to number customer gateways, the risk of +address collision, and therefore routing failures, arises when the +customer network already uses an :rfc:`1918` address space. + +This prompted some ISPs to develop a policy within the :abbr:`ARIN +(American Registry for Internet Numbers)` to allocate new private +address space for CGNs, but ARIN deferred to the IETF before +implementing the policy indicating that the matter was not a typical +allocation issue but a reservation of addresses for technical purposes +(per :rfc:`2860`). + +IETF published :rfc:`6598`, detailing a shared address space for use in +ISP CGN deployments that can handle the same network prefixes occurring +both on inbound and outbound interfaces. ARIN returned address space to +the :abbr:`IANA (Internet Assigned Numbers Authority)` for this +allocation. + +The allocated address block is 100.64.0.0/10. + +Devices evaluating whether an IPv4 address is public must be updated to +recognize the new address space. Allocating more private IPv4 address +space for NAT devices might prolong the transition to IPv6. + +Overview +======== + +Different NAT Types +------------------- + +.. _source-nat: + +SNAT +^^^^ + +:abbr:`SNAT (Source Network Address Translation)` is the most common +form of :abbr:`NAT (Network Address Translation)` and is typically +referred to simply as NAT. To be more correct, what most people refer +to as :abbr:`NAT (Network Address Translation)` is actually the process +of :abbr:`PAT (Port Address Translation)`, or NAT overload. SNAT is +typically used by internal users/private hosts to access the Internet +- the source address is translated and thus kept private. + +.. _destination-nat: + +DNAT +^^^^ + +:abbr:`DNAT (Destination Network Address Translation)` changes the +destination address of packets passing through the router, while +:ref:`source-nat` changes the source address of packets. DNAT is +typically used when an external (public) host needs to initiate a +session with an internal (private) host. A customer needs to access a +private service behind the routers public IP. A connection is +established with the routers public IP address on a well known port and +thus all traffic for this port is rewritten to address the internal +(private) host. + +.. _bidirectional-nat: + +Bidirectional NAT +^^^^^^^^^^^^^^^^^ + +This is a common scenario where both :ref:`source-nat` and +:ref:`destination-nat` are configured at the same time. It's commonly +used then internal (private) hosts need to establish a connection with +external resources and external systems need to access internal +(private) resources. + +NAT, Routing, Firewall Interaction +---------------------------------- + +There is a very nice picture/explanation in the Vyatta documentation +which should be rewritten here. + +NAT Ruleset +----------- + +:abbr:`NAT (Network Address Translation)` is configured entirely on a +series of so called `rules`. Rules are numbered and evaluated by the +underlying OS in numerical order! The rule numbers can be changes by +utilizing the :cfgcmd:`rename` and :cfgcmd:`copy` commands. + +.. note:: Changes to the NAT system only affect newly established + connections. Already established connections are not affected. + +.. hint:: When designing your NAT ruleset leave some space between + consecutive rules for later extension. Your ruleset could start with + numbers 10, 20, 30. You thus can later extend the ruleset and place + new rules between existing ones. + +Rules will be created for both :ref:`source-nat` and +:ref:`destination-nat`. + +For :ref:`bidirectional-nat` a rule for both :ref:`source-nat` and +:ref:`destination-nat` needs to be created. + +.. _traffic-filters: + +Traffic Filters +--------------- + +Traffic Filters are used to control which packets will have the defined +NAT rules applied. Five different filters can be applied within a NAT +rule. + +* **outbound-interface** - applicable only to :ref:`source-nat`. It + configures the interface which is used for the outside traffic that + this translation rule applies to. + + Example: + + .. code-block:: none + + set nat source rule 20 outbound-interface eth0 + +* **inbound-interface** - applicable only to :ref:`destination-nat`. It + configures the interface which is used for the inside traffic the + translation rule applies to. + + Example: + + .. code-block:: none + + set nat destination rule 20 inbound-interface eth1 + +* **protocol** - specify which types of protocols this translation rule + applies to. Only packets matching the specified protocol are NATed. + By default this applies to `all` protocols. + + Example: + + * Set SNAT rule 20 to only NAT TCP and UDP packets + * Set DNAT rule 20 to only NAT UDP packets + + .. code-block:: none + + set nat source rule 20 protocol tcp_udp + set nat destination rule 20 protocol udp + +* **source** - specifies which packets the NAT translation rule applies + to based on the packets source IP address and/or source port. Only + matching packets are considered for NAT. + + Example: + + * Set SNAT rule 20 to only NAT packets arriving from the 192.0.2.0/24 + network + * Set SNAT rule 30 to only NAT packets arriving from the 203.0.113.0/24 + network with a source port of 80 and 443 + + .. code-block:: none + + set nat source rule 20 source address 192.0.2.0/24 + set nat source rule 30 source address 203.0.113.0/24 + set nat source rule 30 source port 80,443 + + +* **destination** - specify which packets the translation will be + applied to, only based on the destination address and/or port number + configured. + + .. note:: If no destination is specified the rule will match on any + destination address and port. + + Example: + + * Configure SNAT rule (40) to only NAT packets with a destination + address of 192.0.2.1. + + .. code-block:: none + + set nat source rule 40 destination address 192.0.2.1 + + +Address Conversion +------------------ + +Every NAT rule has a translation command defined. The address defined +for the translation is the address used when the address information in +a packet is replaced. + +Source Address +^^^^^^^^^^^^^^ + +For :ref:`source-nat` rules the packets source address will be replaced +with the address specified in the translation command. A port +translation can also be specified and is part of the translation +address. + +.. note:: The translation address must be set to one of the available + addresses on the configured `outbound-interface` or it must be set to + `masquerade` which will use the primary IP address of the + `outbound-interface` as its translation address. + +.. note:: When using NAT for a large number of host systems it + recommended that a minimum of 1 IP address is used to NAT every 256 + private host systems. This is due to the limit of 65,000 port numbers + available for unique translations and a reserving an average of + 200-300 sessions per host system. + +Example: + +* Define a discrete source IP address of 100.64.0.1 for SNAT rule 20 +* Use address `masquerade` (the interfaces primary address) on rule 30 +* For a large amount of private machines behind the NAT your address + pool might to be bigger. Use any address in the range 100.64.0.10 - + 100.64.0.20 on SNAT rule 40 when doing the translation + + +.. code-block:: none + + set nat source rule 20 translation address 100.64.0.1 + set nat source rule 30 translation address 'masquerade' + set nat source rule 40 translation address 100.64.0.10-100.64.0.20 + + +Destination Address +^^^^^^^^^^^^^^^^^^^ + +For :ref:`destination-nat` rules the packets destination address will be +replaced by the specified address in the `translation address` command. + +Example: + +* DNAT rule 10 replaces the destination address of an inbound packet + with 192.0.2.10 + +.. code-block:: none + + set nat destination rule 10 translation address 192.0.2.10 + + +Configuration Examples +====================== + +To setup SNAT, we need to know: + +* The internal IP addresses we want to translate +* The outgoing interface to perform the translation on +* The external IP address to translate to + +In the example used for the Quick Start configuration above, we +demonstrate the following configuration: + +.. code-block:: none + + set nat source rule 100 outbound-interface 'eth0' + set nat source rule 100 source address '192.168.0.0/24' + set nat source rule 100 translation address 'masquerade' + +Which generates the following configuration: + +.. code-block:: none + + rule 100 { + outbound-interface eth0 + source { + address 192.168.0.0/24 + } + translation { + address masquerade + } + } + +In this example, we use **masquerade** as the translation address +instead of an IP address. The **masquerade** target is effectively an +alias to say "use whatever IP address is on the outgoing interface", +rather than a statically configured IP address. This is useful if you +use DHCP for your outgoing interface and do not know what the external +address will be. + +When using NAT for a large number of host systems it recommended that a +minimum of 1 IP address is used to NAT every 256 host systems. This is +due to the limit of 65,000 port numbers available for unique +translations and a reserving an average of 200-300 sessions per host +system. + +Example: For an ~8,000 host network a source NAT pool of 32 IP addresses +is recommended. + +A pool of addresses can be defined by using a hyphen between two IP +addresses: + +.. code-block:: none + + set nat source rule 100 translation address '203.0.113.32-203.0.113.63' + +.. _avoidng_leaky_nat: + +Avoiding "leaky" NAT +-------------------- + +Linux netfilter will not NAT traffic marked as INVALID. This often +confuses people into thinking that Linux (or specifically VyOS) has a +broken NAT implementation because non-NATed traffic is seen leaving an +external interface. This is actually working as intended, and a packet +capture of the "leaky" traffic should reveal that the traffic is either +an additional TCP "RST", "FIN,ACK", or "RST,ACK" sent by client systems +after Linux netfilter considers the connection closed. The most common +is the additional TCP RST some host implementations send after +terminating a connection (which is implementation-specific). + +In other words, connection tracking has already observed the connection +be closed and has transition the flow to INVALID to prevent attacks from +attempting to reuse the connection. + +You can avoid the "leaky" behavior by using a firewall policy that drops +"invalid" state packets. + +Having control over the matching of INVALID state traffic, e.g. the +ability to selectively log, is an important troubleshooting tool for +observing broken protocol behavior. For this reason, VyOS does not +globally drop invalid state traffic, instead allowing the operator to +make the determination on how the traffic is handled. + +.. _hairpin_nat_reflection: + +Hairpin NAT/NAT Reflection +-------------------------- + +A typical problem with using NAT and hosting public servers is the +ability for internal systems to reach an internal server using it's +external IP address. The solution to this is usually the use of +split-DNS to correctly point host systems to the internal address when +requests are made internally. Because many smaller networks lack DNS +infrastructure, a work-around is commonly deployed to facilitate the +traffic by NATing the request from internal hosts to the source address +of the internal interface on the firewall. + +This technique is commonly referred to as NAT Reflection or Hairpin NAT. + +Example: + +* Redirect Microsoft RDP traffic from the outside (WAN, external) world + via :ref:`destination-nat` in rule 100 to the internal, private host + 192.0.2.40. + +* Redirect Microsoft RDP traffic from the internal (LAN, private) + network via :ref:`destination-nat` in rule 110 to the internal, + private host 192.0.2.40. We also need a :ref:`source-nat` rule 110 for + the reverse path of the traffic. The internal network 192.0.2.0/24 is + reachable via interface `eth0.10`. + +.. code-block:: none + + set nat destination rule 100 description 'Regular destination NAT from external' + set nat destination rule 100 destination port '3389' + set nat destination rule 100 inbound-interface 'pppoe0' + set nat destination rule 100 protocol 'tcp' + set nat destination rule 100 translation address '192.0.2.40' + + set nat destination rule 110 description 'NAT Reflection: INSIDE' + set nat destination rule 110 destination port '3389' + set nat destination rule 110 inbound-interface 'eth0.10' + set nat destination rule 110 protocol 'tcp' + set nat destination rule 110 translation address '192.0.2.40' + + set nat source rule 110 description 'NAT Reflection: INSIDE' + set nat source rule 110 destination address '192.0.2.0/24' + set nat source rule 110 outbound-interface 'eth0.10' + set nat source rule 110 protocol 'tcp' + set nat source rule 110 source address '192.0.2.0/24' + set nat source rule 110 translation address 'masquerade' + +Which results in a configuration of: + +.. code-block:: none + + vyos@vyos# show nat + destination { + rule 100 { + description "Regular destination NAT from external" + destination { + port 3389 + } + inbound-interface pppoe0 + protocol tcp + translation { + address 192.0.2.40 + } + } + rule 110 { + description "NAT Reflection: INSIDE" + destination { + port 3389 + } + inbound-interface eth0.10 + protocol tcp + translation { + address 192.0.2.40 + } + } + } + source { + rule 110 { + description "NAT Reflection: INSIDE" + destination { + address 192.0.2.0/24 + } + outbound-interface eth0.10 + protocol tcp + source { + address 192.0.2.0/24 + } + translation { + address masquerade + } + } + } + + +Destination NAT +--------------- + +DNAT is typically referred to as a **Port Forward**. When using VyOS as +a NAT router and firewall, a common configuration task is to redirect +incoming traffic to a system behind the firewall. + +In this example, we will be using the example Quick Start configuration +above as a starting point. + +To setup a destination NAT rule we need to gather: + +* The interface traffic will be coming in on; +* The protocol and port we wish to forward; +* The IP address of the internal system we wish to forward traffic to. + +In our example, we will be forwarding web server traffic to an internal +web server on 192.168.0.100. HTTP traffic makes use of the TCP protocol +on port 80. For other common port numbers, see: +https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers + +Our configuration commands would be: + +.. code-block:: none + + set nat destination rule 10 description 'Port Forward: HTTP to 192.168.0.100' + set nat destination rule 10 destination port '80' + set nat destination rule 10 inbound-interface 'eth0' + set nat destination rule 10 protocol 'tcp' + set nat destination rule 10 translation address '192.168.0.100' + +Which would generate the following NAT destination configuration: + +.. code-block:: none + + nat { + destination { + rule 10 { + description "Port Forward: HTTP to 192.168.0.100" + destination { + port 80 + } + inbound-interface eth0 + protocol tcp + translation { + address 192.168.0.100 + } + } + } + } + +.. note:: If forwarding traffic to a different port than it is arriving + on, you may also configure the translation port using + `set nat destination rule [n] translation port`. + +This establishes our Port Forward rule, but if we created a firewall +policy it will likely block the traffic. + +It is important to note that when creating firewall rules that the DNAT +translation occurs **before** traffic traverses the firewall. In other +words, the destination address has already been translated to +192.168.0.100. + +So in our firewall policy, we want to allow traffic coming in on the +outside interface, destined for TCP port 80 and the IP address of +192.168.0.100. + +.. code-block:: none + + set firewall name OUTSIDE-IN rule 20 action 'accept' + set firewall name OUTSIDE-IN rule 20 destination address '192.168.0.100' + set firewall name OUTSIDE-IN rule 20 destination port '80' + set firewall name OUTSIDE-IN rule 20 protocol 'tcp' + set firewall name OUTSIDE-IN rule 20 state new 'enable' + +This would generate the following configuration: + +.. code-block:: none + + rule 20 { + action accept + destination { + address 192.168.0.100 + port 80 + } + protocol tcp + state { + new enable + } + } + +.. note:: + + If you have configured the `INSIDE-OUT` policy, you will need to add + additional rules to permit inbound NAT traffic. + +1-to-1 NAT +---------- + +Another term often used for DNAT is **1-to-1 NAT**. For a 1-to-1 NAT +configuration, both DNAT and SNAT are used to NAT all traffic from an +external IP address to an internal IP address and vice-versa. + +Typically, a 1-to-1 NAT rule omits the destination port (all ports) and +replaces the protocol with either **all** or **ip**. + +Then a corresponding SNAT rule is created to NAT outgoing traffic for +the internal IP to a reserved external IP. This dedicates an external IP +address to an internal IP address and is useful for protocols which +don't have the notion of ports, such as GRE. + +Here's an extract of a simple 1-to-1 NAT configuration with one internal +and one external interface: + +.. code-block:: none + + set interfaces ethernet eth0 address '192.168.1.1/24' + set interfaces ethernet eth0 description 'Inside interface' + set interfaces ethernet eth1 address '192.0.2.30/24' + set interfaces ethernet eth1 description 'Outside interface' + set nat destination rule 2000 description '1-to-1 NAT example' + set nat destination rule 2000 destination address '192.0.2.30' + set nat destination rule 2000 inbound-interface 'eth1' + set nat destination rule 2000 translation address '192.168.1.10' + set nat source rule 2000 description '1-to-1 NAT example' + set nat source rule 2000 outbound-interface 'eth1' + set nat source rule 2000 source address '192.168.1.10' + set nat source rule 2000 translation address '192.0.2.30' + +Firewall rules are written as normal, using the internal IP address as +the source of outbound rules and the destination of inbound rules. + +NAT before VPN +-------------- + +Some application service providers (ASPs) operate a VPN gateway to +provide access to their internal resources, and require that a +connecting organisation translate all traffic to the service provider +network to a source address provided by the ASP. + +Example Network +^^^^^^^^^^^^^^^ + +Here's one example of a network environment for an ASP. +The ASP requests that all connections from this company should come from +172.29.41.89 - an address that is assigned by the ASP and not in use at +the customer site. + +.. figure:: /_static/images/nat_before_vpn_topology.png + :scale: 100 % + :alt: NAT before VPN Topology + + NAT before VPN Topology + + +Configuration +^^^^^^^^^^^^^ + +The required configuration can be broken down into 4 major pieces: + +* A dummy interface for the provider-assigned IP; +* NAT (specifically, Source NAT); +* IPSec IKE and ESP Groups; +* IPSec VPN tunnels. + + +Dummy interface +""""""""""""""" + +The dummy interface allows us to have an equivalent of the Cisco IOS +Loopback interface - a router-internal interface we can use for IP +addresses the router must know about, but which are not actually +assigned to a real network. + +We only need a single step for this interface: + +.. code-block:: none + + set interfaces dummy dum0 address '172.29.41.89/32' + +NAT Configuration +""""""""""""""""" + +.. code-block:: none + + set nat source rule 110 description 'Internal to ASP' + set nat source rule 110 destination address '172.27.1.0/24' + set nat source rule 110 outbound-interface 'any' + set nat source rule 110 source address '192.168.43.0/24' + set nat source rule 110 translation address '172.29.41.89' + set nat source rule 120 description 'Internal to ASP' + set nat source rule 120 destination address '10.125.0.0/16' + set nat source rule 120 outbound-interface 'any' + set nat source rule 120 source address '192.168.43.0/24' + set nat source rule 120 translation address '172.29.41.89' + +IPSec IKE and ESP +""""""""""""""""" + +The ASP has documented their IPSec requirements: + +* IKE Phase: + + * aes256 Encryption + * sha256 Hashes + +* ESP Phase: + + * aes256 Encryption + * sha256 Hashes + * DH Group 14 + + +Additionally, we want to use VPNs only on our eth1 interface (the +external interface in the image above) + +.. code-block:: none + + set vpn ipsec ike-group my-ike ikev2-reauth 'no' + set vpn ipsec ike-group my-ike key-exchange 'ikev1' + set vpn ipsec ike-group my-ike lifetime '7800' + set vpn ipsec ike-group my-ike proposal 1 dh-group '14' + set vpn ipsec ike-group my-ike proposal 1 encryption 'aes256' + set vpn ipsec ike-group my-ike proposal 1 hash 'sha256' + + set vpn ipsec esp-group my-esp compression 'disable' + set vpn ipsec esp-group my-esp lifetime '3600' + set vpn ipsec esp-group my-esp mode 'tunnel' + set vpn ipsec esp-group my-esp pfs 'disable' + set vpn ipsec esp-group my-esp proposal 1 encryption 'aes256' + set vpn ipsec esp-group my-esp proposal 1 hash 'sha256' + + set vpn ipsec ipsec-interfaces interface 'eth1' + +IPSec VPN Tunnels +""""""""""""""""" + +We'll use the IKE and ESP groups created above for this VPN. Because we +need access to 2 different subnets on the far side, we will need two +different tunnels. If you changed the names of the ESP group and IKE +group in the previous step, make sure you use the correct names here +too. + +.. code-block:: none + + set vpn ipsec site-to-site peer 198.51.100.243 authentication mode 'pre-shared-secret' + set vpn ipsec site-to-site peer 198.51.100.243 authentication pre-shared-secret 'PASSWORD IS HERE' + set vpn ipsec site-to-site peer 198.51.100.243 connection-type 'initiate' + set vpn ipsec site-to-site peer 198.51.100.243 default-esp-group 'my-esp' + set vpn ipsec site-to-site peer 198.51.100.243 ike-group 'my-ike' + set vpn ipsec site-to-site peer 198.51.100.243 ikev2-reauth 'inherit' + set vpn ipsec site-to-site peer 198.51.100.243 local-address '203.0.113.46' + set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 local prefix '172.29.41.89/32' + set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 remote prefix '172.27.1.0/24' + set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 local prefix '172.29.41.89/32' + set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 remote prefix '10.125.0.0/16' + +Testing and Validation +"""""""""""""""""""""" + +If you've completed all the above steps you no doubt want to see if it's +all working. + +Start by checking for IPSec SAs (Security Associations) with: + +.. code-block:: none + + $ show vpn ipsec sa + + Peer ID / IP Local ID / IP + ------------ ------------- + 198.51.100.243 203.0.113.46 + + Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto + ------ ----- ------------- ------- ---- ----- ------ ------ ----- + 0 up 0.0/0.0 aes256 sha256 no 1647 3600 all + 1 up 0.0/0.0 aes256 sha256 no 865 3600 all + +That looks good - we defined 2 tunnels and they're both up and running. diff --git a/docs/configuration/nat/nat66.rst b/docs/configuration/nat/nat66.rst new file mode 100644 index 00000000..bcf5570f --- /dev/null +++ b/docs/configuration/nat/nat66.rst @@ -0,0 +1,127 @@ +.. _nat66: + +############ +NAT66(NPTv6) +############ + +:abbr:`NPTv6 (IPv6-to-IPv6 Network Prefix Translation)` is an address translation technology based +on IPv6 networks, used to convert an IPv6 address prefix in an IPv6 message into another IPv6 +address prefix. We call this address translation method NAT66. Devices that support the NAT66 +function are called NAT66 devices, which can provide NAT66 source and destination address +translation functions. + +Overview +======== + +Different NAT Types +------------------- + +.. _source-nat66: + +SNAT66 +^^^^^^ + +:abbr:`SNPTv6 (Source IPv6-to-IPv6 Network Prefix Translation)` The conversion function is mainly used in +the following scenarios: + +* A single internal network and external network. Use the NAT66 device to connect a single internal + network and public network, and the hosts in the internal network use IPv6 address prefixes that + only support routing within the local range. When a host in the internal network accesses the + external network, the source IPv6 address prefix in the message will be converted into a + global unicast IPv6 address prefix by the NAT66 device. +* Redundancy and load sharing. There are multiple NAT66 devices at the edge of an IPv6 network + to another IPv6 network. The path through the NAT66 device to another IPv6 network forms an + equivalent route, and traffic can be load-shared on these NAT66 devices. In this case, you + can configure the same source address translation rules on these NAT66 devices, so that any + NAT66 device can handle IPv6 traffic between different sites. +* Multi-homed. In a multi-homed network environment, the NAT66 device connects to an + internal network and simultaneously connects to different external networks. Address + translation can be configured on each external network side interface of the NAT66 + device to convert the same internal network address into different external network + addresses, and realize the mapping of the same internal address to multiple external addresses. + +.. _destination-nat66: + +DNAT66 +^^^^^^ + +The :abbr:`DNPTv6 (Destination IPv6-to-IPv6 Network Prefix Translation)` destination address translation +function is used in scenarios where the server in the internal network provides services to the external +network, such as providing Web services or FTP services to the external network. By configuring the mapping +relationship between the internal server address and the external network address on the external network +side interface of the NAT66 device, external network users can access the internal network server through +the designated external network address. + +Prefix Conversion +------------------ + +Source Prefix +^^^^^^^^^^^^^ + +Every SNAT66 rule has a translation command defined. The prefix defined +for the translation is the prefix used when the address information in +a packet is replaced.、 + +The :ref:`source-nat66` rule replaces the source address of the packet and calculates the +converted address using the prefix specified in the rule. + +Example: + +* Convert the address prefix of a single `fc01::/64` network to `fc00::/64` +* Output from `eth0` network interface + +.. code-block:: none + + set nat66 source rule 1 outbound-interface 'eth0' + set nat66 source rule 1 source prefix 'fc01::/64' + set nat66 source rule 1 translation prefix 'fc00::/64' + +Destination Prefix +^^^^^^^^^^^^^^^^^^ + +For the :ref:`destination-nat66` rule, the destination address of the packet is +replaced by the address calculated from the specified address or prefix in the +`translation address` command + +Example: + +* Convert the address prefix of a single `fc00::/64` network to `fc01::/64` +* Input from `eth0` network interface + +.. code-block:: none + + set nat66 destination rule 1 inbound-interface 'eth0' + set nat66 destination rule 1 destination address 'fc00::/64' + set nat66 destination rule 1 translation address 'fc01::/64' + +Configuration Examples +====================== + +Use the following topology to build a nat66 based isolated network between internal +and external networks (dynamic prefix is not supported): + +.. figure:: /_static/images/vyos_1_4_nat66_simple.png + :alt: VyOS NAT66 Simple Configure + +R1: + +.. code-block:: none + + set interfaces ethernet eth0 ipv6 address autoconf + set interfaces ethernet eth1 address 'fc01::1/64' + set nat66 destination rule 1 destination address 'fc00:470:f1cd:101::/64' + set nat66 destination rule 1 inbound-interface 'eth0' + set nat66 destination rule 1 translation address 'fc01::/64' + set nat66 source rule 1 outbound-interface 'eth0' + set nat66 source rule 1 source prefix 'fc01::/64' + set nat66 source rule 1 translation prefix 'fc00:470:f1cd:101::/64' + +R2: + +.. code-block:: none + + set interfaces bridge br1 address 'fc01::2/64' + set interfaces bridge br1 member interface eth0 + set interfaces bridge br1 member interface eth1 + set protocols static route6 ::/0 next-hop fc01::1 + set service router-advert interface br1 prefix ::/0 diff --git a/docs/configuration/nat/nptv6.rst b/docs/configuration/nat/nptv6.rst deleted file mode 100644 index c09c8336..00000000 --- a/docs/configuration/nat/nptv6.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. include:: /_include/need_improvement.txt - -.. _nptv6: - -##### -NPTv6 -##### - -:abbr:`NPTv6 (Network Prefix Translation)` is a form of NAT for IPv6. It's -described in :rfc:`6296`. - -**Usage** - -NPTv6 is very useful for IPv6 multihoming. It is also commonly used when the -external IPv6 prefix is dynamic, as it prevents the need for renumbering of -internal hosts when the extern prefix changes. - -Let's assume the following network configuration: - -* eth0 : LAN -* eth1 : WAN1, with 2001:db8:e1::/48 routed towards it -* eth2 : WAN2, with 2001:db8:e2::/48 routed towards it - -Regarding LAN hosts addressing, why would you choose 2001:db8:e1::/48 over -2001:db8:e2::/48? What happens when you get a new provider with a different -routed IPv6 subnet? - -The solution here is to assign to your hosts ULAs_ and to prefix-translate -their address to the right subnet when going through your router. - -* LAN Subnet : fc00:dead:beef::/48 -* WAN 1 Subnet : 2001:db8:e1::/48 -* WAN 2 Subnet : 2001:db8:e2::/48 - -* eth0 addr : fc00:dead:beef::1/48 -* eth1 addr : 2001:db8:e1::1/48 -* eth2 addr : 2001:db8:e2::1/48 - -VyOS Support -^^^^^^^^^^^^ - -NPTv6 support has been added in VyOS 1.2 (Crux) and is available through -`nat nptv6` configuration nodes. - -.. code-block:: none - - set rule 10 source prefix 'fc00:dead:beef::/48' - set rule 10 outbound-interface 'eth1' - set rule 10 translation prefix '2001:db8:e1::/48' - set rule 20 source prefix 'fc00:dead:beef::/48' - set rule 20 outbound-interface 'eth2' - set rule 20 translation prefix '2001:db8:e2::/48' - -Resulting in the following ip6tables rules: - -.. code-block:: none - - Chain VYOS_DNPT_HOOK (1 references) - pkts bytes target prot opt in out source destination - 0 0 NETMAP all eth1 any anywhere 2001:db8:e1::/48 to:fc00:dead:beef::/48 - 0 0 NETMAP all eth2 any anywhere 2001:db8:e2::/48 to:fc00:dead:beef::/48 - 0 0 RETURN all any any anywhere anywhere - Chain VYOS_SNPT_HOOK (1 references) - pkts bytes target prot opt in out source destination - 0 0 NETMAP all any eth1 fc00:dead:beef::/48 anywhere to:2001:db8:e1::/48 - 0 0 NETMAP all any eth2 fc00:dead:beef::/48 anywhere to:2001:db8:e2::/48 - 0 0 RETURN all any any anywhere anywhere - -.. _ULAs: https://en.wikipedia.org/wiki/Unique_local_address