Date: Tue, 19 Oct 2004 11:31:18 +0800 From: Eugene Grosbein <eugen@kuzbass.ru> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: net@freebsd.org Subject: Re: asymmetric NAT Message-ID: <41748A86.B377F2BC@kuzbass.ru> References: <20041018140527.GA441@grosbein.pp.ru> <Pine.BSF.4.53.0410181721100.59402@e0-0.zab2.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Bjoern A. Zeeb" wrote: > > Let's consider a simple scheme with two NAT boxes > > where packet flow is asymmetric: > > > > A----+ > > | | > > S ---+ T > > | | > > B----+ > ... > > A has 2.2.2.2 for its outer interface, B has 3.3.3.3 for its. > > A and B both do "static NAT" for S, they translate > > 192.168.1.1 to 4.4.4.4 (and vise versa). One can try > ... > > AFAIK, libalias and ipnat do not support this configuration currently. > > I'm trying to patch libalias to support this and have some progress > > but still cannot make work active mode FTP transfers when S is a client > > and T is a server. > > > > Should this schema work in a theory at least? > > the only thing I can think of is to have some kind of protocoll > beteween A and B that > > a) in almost realtime syncs states > or > b) queries the other for a known state about the connection in > question and updates it's internal "tables". > > both are problematic and normally addressed in HA software. > > For you scenario an unidirectional syncing would be enough but > if you want to dtrt do it bidirectional because you might not be able > to garantee 100% that all traffic leaves through A and responses > always come in via B. You are right, packet flow can change. But why may I need to sync states of NAT boxes in case of static NAT? Eugene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41748A86.B377F2BC>