On Sun, Apr 04, 2004 at 02:24:05PM +0200, Daniel Hartmeier wrote: Hey there,
Thanks for the reply, > On Thu, Apr 01, 2004 at 04:19:24PM +0100, Joe Warren-Meeks wrote: > > > ------------ > > fxp1 | OpenBSD | fxp0 > > ----------| 3.4 |--------- > > 10.21.21.2/24 | i386 | 10.3.1.130/24 > > ------------ > > > > Now, traffic arriving in on fxp0 going to 10.65.0.0/16 needs to have its > > destination address changed to 10.95.0.0/16 and its source address changed > > to 10.21.21.0/24 (where the host parts of the networks are the same as the > > original) > > > > e.g. A packet arrives in on fxp0 destined to 10.65.1.4 coming from > > 10.88.1.8. This should leave fxp1 with the destination set to 10.95.1.4 and > > the source address of 10.21.21.8 > > First off, all translations (binat, rdr, nat) will only ever translate > one address (source or destination) per state created. You can't > translate both source and destination address with a single translating > state. If you have a recent -current (3.5), make sure to 'set > state-policy if-bound', otherwise you'll likely get state conflicts. Ok, I'm still on 3.4 at the moment, so I'll have to update or wait for 3.5, which I have on pre-order. > So, if you want to translate both addresses, you'll need two state > entries, one on each interface. Luckily, all the connections you > described do pass through both interfaces, so that shouldn't be a > problem. > > You don't want to modify any ports, so if you use nat or rdr, make sure > to disable port translation > > # 10.88.1.8 -> 10.65.1.4 (in fxp0, out fxp1) 10.21.21.8 -> 10.95.1.4 > rdr pass on fxp0 from any to 10.65.0.0/16 -> 10.95.0.0/16 bitmask > nat pass on fxp1 from 10.88.0.0/16 -> 10.21.21.0/24 bitmask static-port I have tried this and I seem to be getting strange results. For the purposes of this test, I had only the rdr rule in place just to check that it was re-writing the destination address properly. bash-2.05b# pfctl -vvss icmp 10.95.1.8:48683 <- 10.65.1.1:48683 <- 10.88.1.8:48683 0:0 age 00:00:04, expires in 00:00:09, 4:0 pkts, 336:0 bytes Now, what it seemed to be doing in the bitmask was taking the host portion of the *source* address and adding that to the 10.95 network portion to create the new destination address, when what I wanted was to take the host portion of the *destination* address and add it to the 10.95 network. It did this with just the rdr and also with the rdr + nat rules in place. Is this how the bitmask works or have I messed something up? > I hope this gets you a little further, it's not exactly a trivial setup, > you'll have to test and debug. Run tcpdump on both interfaces and check > what translations occur. See pfctl -vvss output, you should see two > states (one on fxp0 and fxp1 each). Yeah, it is a horrible setup I have had inflicted on me here. I currently have a working system using linux, but I require two separate rules per destination host and I have around 700 right now, which isn't going to be sustainable as we are about to increase that a fair amount. Thanks again for your help! -- joe. Joe Warren-Meeks Technical Operations Director Inspired Broadcast Networks & The Cloud http://www.inspiredbroadcast.net/ Out of Home Pay to Play Networked Entertainment 1-7, Livonia Street, London W1F 8AD Tel: +44 (0)20 7478 8282 Mob: +44 (0)7789 176078 Fax: +44 (0)20 7287 0131
