OBSD 4.1/NAT port redirection/interception across 7 Class C's

[element]

I've been having quite a bit of issues trying to set this up. Basically i have an openbsd box that filters all inbound/outbound traffic for 7 class c's. I'm implementing ASSP for spam filtering since the previous admin where i work thought it would be a great idea to have all 2000+ ips listen on port 25 for smtp connections. We receive 400-800 simultaneous smtp connections per second. I would like to tunnel these to a dual quad 8gb box i have set up for filtering, however i cant seem to get reverse traffic working. I have no clue if this is even possible, but any information would help.



INTERNET -> DMZ -> OBSD -> xxx.xxx.1-7.xxx


Ideally i would like all connections on 25/587 to redirect to xxx.xxx.3.1

so smtp -> ANY -> xxx.xxx.3.1

table <colo> const { xxx.xxx.1/24, xxx.xxx.2/24, xxx.xxx.3/24, xxx.xxx.4/24, xxx.xxx.5/24, xxx.xxx.6/24, xxx.xxx.7/24}

nat on $ext_if from <colo> -> ($ext_if)

rdr on $ext_if proto tcp from any to <colo> port 25 -> xxx.xxx.3.1 port 26

when i set it up this way the reverse route doesn't seem to complete

pfctl -s state gives the following

all tcp xxx.xxx.3.1:26 <- xxx.xxx.1.1:25 <- HOMEIP:61516 CLOSED:SYN_SENT
all tcp HOMEIP:61516 -> xxx.xxx.3.1:26 SYN_SENT:CLOSED

I'm guessing i need a route-to for each of the subnets/gateways?

[element]

also should note that any of the ips bound on xxx.xxx.3.1 server the redirection works, so if xxx.xxx.2.25 is bound on the same server as xxx.xxx.3.1 then running a telnet to xxx.xxx.xxx..2.25 on port 25 redirects to xxx.xxx.3.1 on port 26 as it should, so i'm guessing it has something to do with the subnets/gateways/nat

[jggimi]

Adding route-to may work, but NATting xxx.xxx.3.1 may work better.

NOTE: There have been many significant structural, performance, and rules syntax changes to PF since 4.1, and you may want to consider replacing or upgrading to a supported release. 4.8 is expected to release next week, on 1 November. Your OS, 4.1, had support dropped on 1 May 2008.

[element]

Originally Posted by jggimi

Adding route-to may work, but NATting xxx.xxx.3.1 may work better.

NOTE: There have been many significant structural, performance, and rules syntax changes to PF since 4.1, and you may want to consider replacing or upgrading to a supported release. 4.8 is expected to release next week, on 1 November. Your OS, 4.1, had support dropped on 1 May 2008.

could you be a bit more specific? possibly give an example pf rule to accomplish what i'm looking for?

[jggimi]

Not really, because I've never used a route-to or reply-to, and PF has changed significantly in this area. The redirection you are using, though, implies NAT, in one direction; NAT provides the translation in the other direction. But I can't tell from your fragment what your network topology really is. It appears you are operating a NAT router for <colo> subnets, and providing a single network interface outbound.

What I meant was to also NAT your xxx.xxx.3.1 spam filter platform, with something like this:

nat on $ext_if from {<colo> xxx.xxx.3.1} -> ($ext_if)

In that way, an inbound packet from the external interface would see a response from this same address, and xxx.xxx.3.1 would never be used in any outbound packet.

But I am confused by your three rules, because I do not understand your topology. I'm also no expert. If your <colo> subnets are NATted through a single IP address going out, your last rule may never match, unless there are addresses in <colo> which are in MX records somewhere, and routing tables go through your router to get there. But then NAT could not be used, so that SMTP sessions behave as expected.