pf redirect question

[Jonathan Horne]

On Wednesday 26 September 2007 08:10:18 Nikos Vassiliadis wrote:
> Please CC me when replying to me, since I will
> see your replies in no time. Otherwise your reply
> might not be seen, since it ends up in another
> directory in my maildir.
>
> On Wednesday 26 September 2007 15:18, Jonathan Horne wrote:
> > On Wednesday 26 September 2007 02:28:48 Nikos Vassiliadis wrote:
> > > No, don't use the IP on your server. Why you should do such a thing?
> >
> > why not?  i did specify that the old server is decommissioning and would
> > be permenantly downed.
>
> Because the IP you will use on the host running FreeBSD and PF has
> nothing to do with FreeBSD and PF. If you do this, you understand
> that packets will be processed locally by FreeBSD's TCP/IP stack
> and not forwarded to the new server, right?
>
> You only want PF to alter the address from old server to new server
> as I said previously. Not accept the packet as if destined for localhost!
>
> > > You just have to make sure that packets ($old_server <-> $world)
> > > are routed through your $pf box. I guess that's the case for you.
> > > pf will just translate the destination address from $old_server
> > > to $new_server.
> >
> > yes, any client or server would be able to route across the wan to the
> > new ip at the other end.
>
> Something like this:
> client-a    client-b
>
> ( internet cloud )
>
>     (pf)--------(new-server)
>
>
> (old-server)
>
> > > BUT, which is this service you are talking about? Cause that's not
> > > feasible with everything.
> >
> > ultimately, i want to route some Mcafee ePolicy clients to use another
> > server.
>
> Yes, I know nothing about it. Is redirecting TCP port 8080 enough?
>
> [snip]
>
> > was my syntax in my example incorrect?
>
> Yes, try removing the interface, just to be more general,
> until you figure it out. Something like:
> rdr inet proto tcp from any to x.x.x.x port = ssh -> y.y.y.y port 22
>
> And use "pfctl -vsnat" to check the state of the rdr command, like this:
>   [ Evaluations: 3434      Packets: 14        Bytes: 840         States: 0 
>    ]
>
> Be sure that every host involved is reachable from the pf box.
>
> Nikos

well, the example you sent me worked... but just for a moment.  as soon as i 
changed it (and restarted pf, its not worked since.  if im going to get this 
to work, this is actually more of the diagram im working with here:

(pf) --- (old server) -- client-a
|
(SITE-A) ---- (vpn-client-b)
|
(internet-cloud) ---- (SITE-B) --- (new server)
|
(SITE-C)
|
(client-c)

where you see SITE-x, consider that the appropricate clusters of routers, 
vpn-endpoints/concentrators.  client-a, old server, and pf are same-lan, 
other objects are all across a wan at different subnets, but all can reach 
all.  (client-b's vpn concentrator is located in the SITE-A routers).

so, if it worked one time and then stopped after a change... where could i be 
going wrong now?  after a change like that, do arp or routing tables need to 
be flushed (and if so, at both the pf, and possibly test subject (but maybe 
not the recieving end of the rdr... i cant see how the receiver would care)

man, if i can get this to work reliably, this is going to save a ton of time 
and trouble!

thanks,
-- 
Jonathan Horne
http://dfwlpiki.dfwlp.org
freebsd at dfwlp.com