[tarballed]

I'm coming across a weird thing going on with my OpenBSD mail gateway box. I've been playing with this for a better part of the morning, and I think the problem is a routing issue.

Please see this prior thread for a bit of background info:

http://screamingelectron.org/phpBB2/viewtopic.php?t=1037&highlight=

Required info:

OpenBSD 3.3
Mail Gateway on the DMZ
DMZ subnet: 10.0.1.1/24
fxp0 = 10.0.1.80
fxp1 = 10.0.1.100
/etc/mygate = 10.0.1.1

Private Network: 192.168.1.0/24
IP Address of mail server = 192.168.1.165

Here is what is going on:
When I fire up my PF rules, mail is not being relayed to my internal mail server. When I shut the rules off, mail IS relayed to the internal mail server.

My rules:

ext_if="fxp0" # External Interface
int_if="fxp1"
int_net="192.168.1.0/24"
tcp_services = "{ 25 }"
tcp_int_services = "{ 22 }"

#Tables
table <NoRouteIPs> { 127.0.0.1/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, !192.168.0.0/24 }
table <trusted> persist file "/etc/tables/trusted"

# Clean up fragmented and abnormal packets
scrub in all

#default Deny all
block in log on $ext_if all

#loopback rules
pass in quick on lo0 all

# don't allow anyone to spoof non-routeable addresses
block in log quick on $ext_if from <NoRouteIPs> to any
block out log quick on $ext_if from any to <NoRouteIPs>

#Passing in email
pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services flags S/SAFR keep state

# pass trusted for SSH
pass in log quick on $int_if inet proto tcp from <trusted> to $int_if port 22 keep state

# and let out-going traffic out and maintain state on established connections
pass out on $int_if from any to $int_if:network keep state
pass out on $ext_if proto tcp all modulate state flags S/SAFR
pass out on $ext_if proto { udp, icmp } all keep state
[/code:1:7c99153a32]

[snip from maillog]

[code:1:7c99153a32]Oct 1 10:11:26 blowfish postfix/smtp[26912]: connect to 192.168.1.165[192.168.1.165]: No route to host (port 25)
Oct 1 10:11:26 blowfish postfix/smtp[26912]: 2AE731B0949: to=<jwilliams@courtesymortgage.com>, relay=none, delay=0, status=deferred (connect to 192.168.1.165[192.168.1.165]: No route to host)[/code:1:7c99153a32]

No route to host.Hmm.

Entry from my pflog:

[code:1:7c99153a32]Oct 01 10:11:26.711858 rule 3/0(match): block out on fxp0: 10.0.1.80.30123 > 192.168.1.165.25: S 3073788046:3073788046(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 901711457 0> (DF)[/code:1:7c99153a32]

Granted, this is with the PF rules up. When they are down, mail is relayed just fine.

Ok. With that in mind, when the rules are up, I cant ping my gateway. I get no route output.

My thinking is that, I obviously have something backward. For some reason, mail, when going to the trusted network, is going out the external interface and that does not seem correct. I think it should go out through the internal interface.

One thing I should mention: I did setup a rule on the company firewall. A smtp-filter rule that will allow traffic from 10.0.1.100 (fxp1) to 192.168.1.165. I was trying to isolate the direction of traffic and which direction it can flow.

Anyone have any suggestions on what im missing?
If anyone needs additional output, let me know. I'll put it up as quickly as possible.

Thanks.

[bsdjunkie]

fxp0 = 10.0.1.80
fxp1 = 10.0.1.100
...
ext_if="fxp0" # External Interface
int_if="fxp1"



I dont know if its possible to have the internal and external nets on the same subnetwork. 10.0.1.X

[frisco]

snip snip snip...

[code:1:d8204129db]
table <NoRouteIPs> { 127.0.0.1/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, !192.168.0.0/24 }

# don't allow anyone to spoof non-routeable addresses
block in log quick on $ext_if from <NoRouteIPs> to any
block out log quick on $ext_if from any to <NoRouteIPs>
[/code:1:d8204129db]

[code:1:d8204129db]Oct 01 10:11:26.711858 rule 3/0(match): block out on fxp0: 10.0.1.80.30123 > 192.168.1.165.25: S 3073788046:3073788046(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 901711457 0> (DF)[/code:1:d8204129db]


NoRouteIPs contains 10.0.0.0/8 and 192.168.0.0/16 and that is what this log shows in action - both those ip's are ones that you are blocking. Also what bsdjunkie says is true - your probably want fxp1 to have an ip in the 192.168.1.0/24 range, though i'm a bit confused as to how packets get through when the firewall rules are down - do you have bridging set up?

[tarballed]

Hey guys..thanks for replying.

NoRouteIPs contains 10.0.0.0/8 and 192.168.0.0/16 and that is what this log shows in action - both those ip's are ones that you are blocking. Also what bsdjunkie says is true - your probably want fxp1 to have an ip in the 192.168.1.0/24 range, though i'm a bit confused as to how packets get through when the firewall rules are down - do you have bridging set up?

No bridging, but I did more testing to try and rule out any potential blunders. :)

though i'm a bit confused as to how packets get through when the firewall rules are down

I figured this one out:

One thing I should mention: I did setup a rule on the company firewall. A smtp-filter rule that will allow traffic from 10.0.1.100 (fxp1) to 192.168.1.165.

Ok..further tested this rule. I have to have a smtp-filter rule to allow any smtp traffic from my DMZ to my trusted network. I brought down both this rule as well as PF rules and traffic was not being relayed to my trusted network. So I have to explicitly say which IP address can transmit traffic from the DMZ to my network. That too wordy? :/

So its kinda screwy really. :)
Any suggestions on how to work around this? I guess I could just remove the entry from my table, correct?

Thanks guys for your help

[tarballed]

NoRouteIPs contains 10.0.0.0/8 and 192.168.0.0/16 and that is what this log shows in action - both those ip's are ones that you are blocking

What about explicitly allowing certain IP's. Can yout put an IP in the table with a preceding ! ?

Also, shouldn't traffic go out through fxp1 and not fxp0?

Trying to brainstorm here and see if I can resolve this asap.

[bsdjunkie]

What about explicitly allowing certain IP's. Can yout put an IP in the table with a preceding ! ?

This is possible, Check out http://www.openbsd.org/faq/pf/tables.html

Addresses can also be specified using the negation (or "not") modifier such as:

table <goodguys> { 192.0.2.0/24, !192.0.2.5 }

The goodguys table will now match all addresses in the 192.0.2.0/24 network except for 192.0.2.5.

[frisco]

How exaclty do you have this machine hooked up to the network? It has three if's, but where do these if's physically connect to the network (into what switches, what else is plugged into those switches, etc)?

[tarballed]

How exaclty do you have this machine hooked up to the network? It has three if's, but where do these if's physically connect to the network (into what switches, what else is plugged into those switches, etc)?

Ok. This is how it currently is setup:


Traffic comes in and hits our Firewall.
I've setup a SMTP Proxy at the firewall level to forward port 25 traffic to my mail gateway on the DMZ.

The cable, from the 'optional' interface on the firewall, runs into a 16 port switch (non-managed). I then plugged in my mail gateway into this particular switch. The Mail Gateway is the only server that is currently plugged into the 'DMZ Switch' if we could call it that.

That is pretty much it.

What I had to do was setup a Filtered-SMTP rule that would allow traffic from my DMZ to my trusted network (pass traffic to the internal mail server). Without this rule, no traffic gets passed to my trusted network.

My thinking is that its something with the firewall itself. It's not a very good firewall in my opinion. Does the job, but its kinda screwy at times.

Here is how a the Filtered-SMTP firewall rule looks:
It has two tabs: Incoming and Outgoing:

On the Incoming tab, I specified the following:
From: 10.0.1.80 (Mail Gateway)
To: 192.168.1.165 (Mail Server on trusted network)

On the outgoing tab, I have this:
From: Any
To: Any

Thats really all there is.

That help?

Thanks for everyones help.

[tarballed]

Uggh. I still cant figure this sucker out.
I contaced our Firewall Vendor and all they completely clueless. :(

I'm guessing, that this is something to do with the filtered-SMTP firewall rule I have to implement in order for traffic to get from the DMZ to my trusted network.

I can't yet put a finger on it...

ANy other suggestions?

Thanks.