natd question
Hi, I want to set up a test network which (partly) mirrors our production side network. To match reality as close as possible we keep the IP addresses in the test network the same as in the production network. In order not to run around with tapes between the two networks, I would like to create the following setup: (~~) (~~) () +-+ () + + | | + + ( 130.144.120/22 ) -- | FreeBSD | -- ( 130.144.120/22 ) +(real)+ | | +(test)+ () +-+ () (~~) (~~) I envision on the FreeBSD box some kind of mapping between the real and test network's IP addresses. Something along the following lines: 130.144.120.10 -> 10.0.0.10 +++-+++ ||| ||| | 130.144.120.10 | -- | FreeBSD | -- | 130.144.120.10 | || || | ||| ++ |+-+ |++ | | |<--- SRC = 130.144.120.10 | DST = 10.0.0.10 | <--- SRC = 10.0.0.10 DST = 130.144.120.10 ---> SRC = 130.144.120.10 DST = 10.0.0.10 ---> SRC = 10.0.0.10 DST = 130.144.120.10 Assuming routes are configured properly, is this possible using natd? Regards, Hans -- Hans Zuidam e-mail: [EMAIL PROTECTED] Origin, BAS/AM-CE tel. +31 40 2735569 Gebouw SK-520 fax. +31 40 2736936 Glaslaan 2 5616 LW Eindhoven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd question
On Tue, 19 Oct 1999, Zuidam, Hans wrote: > I want to set up a test network which (partly) mirrors our production > side network. To match reality as close as possible we keep the IP > addresses in the test network the same as in the production network. In > order not to run around with tapes between the two networks, I would like > to create the following setup: > > ( 130.144.120/22 ) -- | FreeBSD | -- ( 130.144.120/22 ) > +(real)+ | | +(test)+ Ew. There's no way the system can differentiate between the two. It'll probably scream bloody murder when the ARPs start flying. You'll generate megabytes of 'arp: 130.144.120.5 changed from XX to Y' messages. I'd suggest assigning fake addresses to to your test network's primary IPs. Once your setup is complete unplug one of the networks from the bsd box then throw all the IPs over to the real IPs. I assume the two networks don't need to talk to one another once you have the test harness set up. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd question
On Tue, 19 Oct 1999, Zuidam, Hans wrote: > I want to set up a test network which (partly) mirrors our production > side network. To match reality as close as possible we keep the IP > addresses in the test network the same as in the production network. In > order not to run around with tapes between the two networks, I would like > to create the following setup: > >(~~) (~~) > () +-+ () > + + | | + + > ( 130.144.120/22 ) -- | FreeBSD | -- ( 130.144.120/22 ) > +(real)+ | | +(test)+ > () +-+ () >(~~) (~~) You can't split 2 identical networks, with identical netmasks across 2 interfaces unless you are running some sort of BRIDGE or transparent proxy support. Even then, if you have the same IP's on both networks you will run into problems with routing and ARP entries on the FreeBSD machine. If you are looking to connect the 2 networks together, run a different ip range on the (test) network, like the 10.0.0.0 or 192.168 network. If you are not connecting to the internet then you will not need to run NATD, just make sure that the gateway address of the machines on both sides are pointing to the corresponding FreeBSD interface IP. *** Nick Rogness Shaw's Principle: System Administrator Build a system that even a fool RapidNet, INC can use, and only a fool will [EMAIL PROTECTED] want to use it. *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: natd question
Hi, My original question was how to connect two identical (that is: two networks using the same IP addresses) together. Both Doug White and Nick Rogness remarked something which I overlooked: arp. My initial idea was to have a daemon "in between" which would swap IP addresses. But of course you have to swap ethernet addresses too. Guess its back to the drawing board. Thanks for the quick answers! Hans -- Hans Zuidam e-mail: [EMAIL PROTECTED] Origin, BAS/AM-CE tel. +31 40 2735569 Gebouw SK-520 fax. +31 40 2736936 Glaslaan 2 5616 LW Eindhoven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd question
On Tue, 19 Oct 1999, Nick Rogness wrote: > On Tue, 19 Oct 1999, Zuidam, Hans wrote: > > > I want to set up a test network which (partly) mirrors our production > > side network. To match reality as close as possible we keep the IP > > addresses in the test network the same as in the production network. In > > order not to run around with tapes between the two networks, I would like > > to create the following setup: > > > >(~~) (~~) > > () +-+ () > > + + | | + + > > ( 130.144.120/22 ) -- | FreeBSD | -- ( 130.144.120/22 ) > > +(real)+ | | +(test)+ > > () +-+ () > >(~~) (~~) > > > You can't split 2 identical networks, with identical > netmasks across 2 interfaces unless you are running some sort of > BRIDGE or transparent proxy support. Even then, if you have the > same IP's on both networks you will run into problems with routing > and ARP entries on the FreeBSD machine. > > If you are looking to connect the 2 networks together, run a > different ip range on the (test) network, like the 10.0.0.0 > or 192.168 network. If you are not connecting to the internet then > you will not need to run NATD, just make sure that the > gateway address of the machines on both sides are pointing to the > corresponding FreeBSD interface IP. > > How about: (~~) (~~) () +---+ +---+ () + + | | | |+ + ( 130.144.120/22 ) -- |FreeBSD| |FreeBSD| --( 130.144.120/22 ) +(real)+ | | | |+(test)+ () +---+ +---+ () (~~) (~~) Using 10.0.0.0 on the network in the middle Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: natd question
> -Original Message- > From: Brian Beattie [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 19 October, 1999 19:27 > How about: > > (~~) (~~) >() +---+ +---+ () > + + | | | |+ + > ( 130.144.120/22 ) -- |FreeBSD| |FreeBSD| --( 130.144.120/22 ) > +(real)+ | | | |+(test)+ > ( ) +---+ +---+ ( ) > (~~) (~~) > > Using 10.0.0.0 on the network in the middle That will only work if the link in the middle is a point-to-point link. Hmmm, maybe PLIP will give some reasonable performance there. The other "solution" would be to have an ARP table for each individual interface for the duplicate addresses. This would involve an extensive of the ARP code to which I'm not quite up to. Regards, Hans -- Hans Zuidam e-mail: [EMAIL PROTECTED] Origin, BAS/AM-CE tel. +31 40 2735569 Gebouw SK-520 fax. +31 40 2736936 Glaslaan 2 5616 LW Eindhoven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd question
On Tue, 19 Oct 1999, Brian Beattie wrote: :On Tue, 19 Oct 1999, Nick Rogness wrote: : :> On Tue, 19 Oct 1999, Zuidam, Hans wrote: :> :> > I want to set up a test network which (partly) mirrors our production :> > side network. To match reality as close as possible we keep the IP :> > addresses in the test network the same as in the production network. In :> > order not to run around with tapes between the two networks, I would like :> > to create the following setup: :> > :> >(~~) (~~) :> > () +-+ () :> > + + | | + + :> > ( 130.144.120/22 ) -- | FreeBSD | -- ( 130.144.120/22 ) :> > +(real)+ | | +(test)+ :> > () +-+ () :> >(~~) (~~) :> :> :> You can't split 2 identical networks, with identical :> netmasks across 2 interfaces unless you are running some sort of :> BRIDGE or transparent proxy support. Even then, if you have the :> same IP's on both networks you will run into problems with routing :> and ARP entries on the FreeBSD machine. :> :> If you are looking to connect the 2 networks together, run a :> different ip range on the (test) network, like the 10.0.0.0 :> or 192.168 network. If you are not connecting to the internet then :> you will not need to run NATD, just make sure that the :> gateway address of the machines on both sides are pointing to the :> corresponding FreeBSD interface IP. :> :> : :How about: : :(~~) (~~) : () +---+ +---+ () : + + | | | |+ + : ( 130.144.120/22 ) -- |FreeBSD| |FreeBSD| --( 130.144.120/22 ) : +(real)+ | | | |+(test)+ : () +---+ +---+ () :(~~) (~~) : :Using 10.0.0.0 on the network in the middle You're going to have to work some magic even for that. You've got two boxes who both think 130.144.120/22 is a directly connected network. Routing to the other network without confusing your routers is going to be tricky, if it's even possible. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd question
On Tue, 19 Oct 1999, Brian Beattie wrote: [snip] > > How about: > > (~~) (~~) >() +---+ +---+ () > + + | | | |+ + > ( 130.144.120/22 ) -- |FreeBSD| |FreeBSD| --( 130.144.120/22 ) > +(real)+ | | | |+(test)+ >() +---+ +---+ () > (~~) (~~) > > Using 10.0.0.0 on the network in the middle > I originally had this idea but the problem is when a machine from the 'test' network, lets say 130.144.120.1, tries to reach a machine on the 'real' network, let's say 130.144.120.2. Packets will never be routed properly because it will never leave the 'test' network. The machines on both sides would not send the packets to the gateway since the the destination is considered to be local. Unless there is specific static routes on all machines pointing to higher netmasked hosts they will never be routed across the BSD machines. Even if they were to make it across the return packets would never make it back unless there were static routes on the other side as well. Even if you did get the routing tables setup right on both sides you would then also have to deal with duplicate IP addresses, on a LAN. I have just thought of a way to keep the the ip addresses the same and let NATD handle the IP pointers. However, there will be some renumbering involved: (~~) 10.11.0.0/30 (~~) () +---+ +---+ () + + | | | |+ + ( 10.10.0.0/22 ) -- |FreeBSD| |FreeBSD| -- ( 10.10.0.0/22 ) +(real)+ | | | |+(test)+ () +---+ +---+ () (~~) NATD-1NATD-2(~~) If you setup 2 different machines with 2 ethernet cards in them, configure them to connect to each other with a different network range from the remote sides. Run NatD on those interfaces. Then you setup 2 different address translation tables on each FBSD machine that has static pointers to the real machine IP's using the natd config table eg: #NATD-1 config file port 8668 interface de0 redirect_address 10.10.0.1 130.144.120.1 redirect_address 10.10.0.2 130.144.120.2 redirect_address 10.10.0.3 130.144.120.3 . . . redirect_address 10.10.0.20 130.144.120.19 #NATD-2 config file port 8668 interface de0 redirect_address 10.10.0.1 130.144.120.20 redirect_address 10.10.0.2 130.144.120.25 redirect_address 10.10.0.3 130.144.120.35 . . . redirect_address 10.10.0.20 130.144.120.60 Then you just refer to the machines when communicating between each network as 130.144.120.XXX. That way the FreeBSD machines make the decision on which public packets need to get diverted to which local machine. Also you can change these mappings fairly easily and your mappings will take place without ever having to change IP addresses on your local machines. Just an idea. *** Nick Rogness Shaw's Principle: System Administrator Build a system that even a fool RapidNet, INC can use, and only a fool will [EMAIL PROTECTED] want to use it. *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd question
> >() +---+ +---+ () > > + + | | | |+ + > > ( 130.144.120/22 ) -- |FreeBSD| |FreeBSD| --( 130.144.120/22 ) > > +(real)+ | | | |+(test)+ > >() +---+ +---+ () > > (~~) (~~) If the whole purpose of this is to (as stated in the original message) avoid running Sneakernet between the two networks, why not use a protocol that really doesn't care about IP addresses, network masks, etc. -- possibly UUCP... It's pretty easy to set up, and if you run it over a 115200 baud serial line, performance is quite adequate for most things, and you won't have to deal with the fact that the two nets share addressing. If you're not planning on using UUCP in common use on the final production network, the changes you'd have to make in the config files for it between the two networks wouldn't make a bit of difference once testing is done -- even if you were, the changes still shouldn't make any difference unless you intentionally tried to create problems. (mental reference to a recent thread on -security, I believe:) ) --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
statefull packet filter together with natd question
Hello, Some time a go I posted the same question to freebsd-questions, but uptill now I didn't get an answer. Currently I'm trying to move towards a statefull packet filter. When testing without nat all seems to work fine. But when I added natd (as the first rule) packets that were natd-ed on their way out had their return traffic blocked. The question is, what am I doing wrong?!? I hope somebody can tell me how to solve this problem. Rene from my logs: ipfw: Accept TCP 212.238.x.x:1026 x.x.x.x:23 out via isp0 ipfw: Deny TCP x.x.x.x:23 192.168.1.3:1026 in via isp0 ipfw rules: /sbin/ipfw -f flush /sbin/ipfw -q add divert natd all from any to any via isp0 /sbin/ipfw -q add allow all from any to any via lo0 /sbin/ipfw -q add allow all from any to any via dc0 /sbin/ipfw -q add check-state from any to any via isp0 /sbin/ipfw -q add deny log tcp from any to any established /sbin/ipfw -q add allow all from any to any out via isp0 keep-state /sbin/ipfw -q add deny log all from any to any -- Rene de Vrieshttp://www.tcja.nl mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: statefull packet filter together with natd question
> Hello, > > Some time a go I posted the same question to freebsd-questions, but uptill now > I didn't get an answer. > > Currently I'm trying to move towards a statefull packet filter. When testing > without nat all seems to work fine. But when I added natd (as the first > rule) packets that were natd-ed on their way out had their return traffic > blocked. The question is, what am I doing wrong?!? nat changes addresses and then reinjects packets in the firewall. Chances are that there is no dynamic rule matching the packet after the translation. cheers luigi > I hope somebody can tell me how to solve this problem. > > Rene > > from my logs: > > ipfw: Accept TCP 212.238.x.x:1026 x.x.x.x:23 out via isp0 > ipfw: Deny TCP x.x.x.x:23 192.168.1.3:1026 in via isp0 > > ipfw rules: > > /sbin/ipfw -f flush > > /sbin/ipfw -q add divert natd all from any to any via isp0 > > /sbin/ipfw -q add allow all from any to any via lo0 > /sbin/ipfw -q add allow all from any to any via dc0 > > /sbin/ipfw -q add check-state from any to any via isp0 > /sbin/ipfw -q add deny log tcp from any to any established > /sbin/ipfw -q add allow all from any to any out via isp0 keep-state > > /sbin/ipfw -q add deny log all from any to any > > -- > Rene de Vrieshttp://www.tcja.nl mailto:[EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: statefull packet filter together with natd question
On Wed, Dec 20, 2000 at 09:57:18AM -0800, Luigi Rizzo wrote: > > Currently I'm trying to move towards a statefull packet filter. When testing > > without nat all seems to work fine. But when I added natd (as the first > > rule) packets that were natd-ed on their way out had their return traffic > > blocked. The question is, what am I doing wrong?!? > > nat changes addresses and then reinjects packets in the firewall. > Chances are that there is no dynamic rule matching the > packet after the translation. This is what I know, the problem is how to nat at the right time. I played with two natting rules, one for incoming and one for outgoing traffic (to the same nat process) but I didn't got working. This made me think that there should be a simple solution to this problem. -- Rene de Vrieshttp://www.tcja.nl mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
