+tcp_services = "{ssh, sftp, imap, imaps, smtp, 587, pop3 \
+ domain, ntp, www, http, https}"
+udp_services= "{domain, ntp}"
+
+
+set skip on lo
+set loginterface $ext_if
+
+scrub in all random-id fragment reassemble
+
+block return in log all
+block out all
+
+antispoof quick for $ext_if
+
+
+pass out quick on $ext_if proto tcp to any port $tcp_services
+pass out quick on $ext_if proto udp to any port $udp_services
+
+pass in on $ext_if proto tcp from any to any port ssh flags S/SA synproxy state
+pass in on $ext_if proto tcp from any to any port smtp flags S/SA synproxy state
+pass in on $ext_if proto tcp from any to any port http flags S/SA synproxy state
+pass in on $ext_if proto tcp from any to any port https flags S/SA synproxy state
+pass in on $ext_if proto tcp from any to any port pop3 flags S/SA synproxy state
+pass in on $ext_if proto udp from any to any port domain
+pass in on $ext_if proto tcp from any to any port domain flags S/SA synproxy state

You are blocking ICMP traffic, as part of your default block rule. You may want it, as it would allow ping, traceroute, and similar information to flow unimpeded.

It is not clear, from your last post, what platform you were running your failed curl command from, and the path it would take to connect to 192.168.0.200. Were you running this from the firewall, or from another platform on the network that connects to 0.200 *through* the firewall?

If it is going through your router, did you enable the IP forwarding sysctl?
Does the curl connection function correctly when pf is disabled?

You are blocking ICMP traffic, as part of your default block rule. You may want it, as it would allow ping, traceroute, and similar information to flow unimpeded.

It is not clear, from your last post, what platform you were running your failed curl command from, and the path it would take to connect to 192.168.0.200. Were you running this from the firewall, or from another platform on the network that connects to 0.200 *through* the firewall?

If it is going through your router, did you enable the IP forwarding sysctl?
Does the curl connection function correctly when pf is disabled?

Everything is behind the firewall/router and I'm doing nightly dumps on my openbsd server and then I use curl to ftp the dumps to another server. Thanks I'll allow ICMP traffic to come on in. Setting up pf for a client server is different from a firewall which is the reason of the clumsy mistakes.

If so, then your problem is not PF, nor is it the router, its that your two boxes are addressed incorrectly.

In order to communicate via IP on the same network, they must have addresses in the same IP subnet.

e.g.: If the receiving box at 192.168.0.200 is using the netmash 255.255.255.0, also known as a /24 block, then the sending box needs to have an address in the same block, somewhere between 192.168.0.1 and 192.168.0.254. If a different netmask is used, the range of addresses in the subnet will expand or contract accordingly.

If I've misunderstood, please clarify your topology and addressing, which are guesses, since you haven't articulated it clearly.

This would point to pf as the culprit, so I wonder if 'No route to host' is reported when pf is set to 'block drop' (as it implicitly is for outgoing traffic). May be a coincidence, so we're keenly awaiting a network diagram nested in [code] tags

ext_if="re0"
tcp_services = "{ssh, ftp, sftp, imap, imaps, smtp, 587, pop3 \
domain, ntp, www, http, https}"
udp_services= "{domain, ntp}"
### allow ping / pong ####
icmp_types = "{ echoreq, unreach }"
set skip on lo
set loginterface $ext_if
scrub in all random-id fragment reassemble
block return in log all
block log out all
antispoof quick for $ext_if
pass out quick on $ext_if proto tcp to any port $tcp_services
pass out quick on $ext_if proto udp to any port $udp_services
# Allow trace route
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep stat
e
pass in on $ext_if proto tcp from any to any port ssh flags S/SA synproxy state
pass in on $ext_if proto tcp from any to any port smtp flags S/SA synproxy state
pass in on $ext_if proto tcp from any to any port http flags S/SA synproxy state
pass in on $ext_if proto tcp from any to any port https flags S/SA synproxy state
pass in on $ext_if proto tcp from any to any port pop3 flags S/SA synproxy state
pass in on $ext_if proto udp from any to any port domain
pass in on $ext_if proto tcp from any to any port domain flags S/SA synproxy state
pass inet proto icmp all icmp-type $icmp_types keep state

Guess #1: Both servers are on the same physical infrastructure.
Guess #2: That doesn't matter, because the servers are on different IP subnets, and cannot communicate directly.
Guess #3: Because they are on different subnets, packets between them must be routed. This adds a "hop" and unnecessary replication of traffic on the physical infrastructure, and adds resource consumption on the router, as well.
Guess #4: Pings fail because ICMP was blocked.
Guess #5: ftp fails because only port 21 control traffic is passed, the backchannel traffic is blocked. A review of the "Issues with FTP" chapter of the PF User's guide is recommended.

If these guesses are wrong, it's because your information continues to be misleading / unclear / incomplete. If you want better guesses, or responses that are actual answers, you will have to provide better info.

I just noticed that these various pf.conf rule sets only have one NIC, $ext_if (re0). Assuming, for the moment, that there is a second NIC, there are no pass in rules for its traffic. All traffic initiated on a local LAN (assuming there is one) will be blocked, except for the limited set of ICMP traffic added to your second pf.conf example.

Let's start over, and have you spoon feed us information, since every time you reply, we get different, and yet still incomplete information.

So I'll ask a few initial, basic questions, and you provide answers. OK?

1. What is the IP address and netmask of your mail server?
2. What is the netmask of your file server at 0.200?
3. a) Is your failure to ftp occuring when you try to connect from your mail server? Yes or no? If no, b) was it when you were trying to connect from your router/firewall to your file server? Yes or no? If no, c) what is the IP address and netmask of the device you failed-to-connect with?

Let's start over, and have you spoon feed us information, since every time you reply, we get different, and yet still incomplete information.

So I'll ask a few initial, basic questions, and you provide answers. OK?

1. What is the IP address and netmask of your mail server?
2. What is the netmask of your file server at 0.200?
3. a) Is your failure to ftp occuring when you try to connect from your mail server? Yes or no? If no, b) was it when you were trying to connect from your router/firewall to your file server? Yes or no? If no, c) what is the IP address and netmask of the device you failed-to-connect with?

I still have no clarity about what system you were trying to connect to 0.200 with and getting failures. Your answers to #3 were unhelpful:

For 3a you stated that you did not have trouble connecting to the file server (0.200) from the mail server (0.4).

For 3b you stated that you did not have trouble connecting to the file server (0.200) from your router/firewall (address unknown). You also stated that when PF was disabled, you didn't have trouble from the mail server. But you'd already denied having communication trouble in 3a.

For 3c you stated that the device you had trouble connecting to the file server (0.200) was the file server(0.200).

So, giving up, forever, and making the assumption that your mail server and its individual PF configuration is the source of your problem, log onto it and use:

# tcpdump -neti pflog0 action block

That will show you, in real time, what type of IP traffic is being blocked, if you manage to retain the "log" options in your two block rules. What's critical for repairing the problem is for you to understanding what traffic is being blocked, why that traffic is necessary, then writing appropriate pass rules.

In the future please volunteer as much information as possible revzalot, otherwise you're forcing us to guess how you've configured your systems after installation.

Nobody here has to take the time and effort to search your previous posts to get an outlook of your network topology, it's simply unreasonable to assume we will.

In the future, think of this forum as a proverbial dump(8) site.. nobody will complain if you give them too much information, although be sure not to leak any sensitive information if you're employed by someone.

Here partial list of information that should be included when reporting routing/networking issues:

Try to describe your problem in as much details as possible, using your own words.. remembering we do not have physic powers.

Perhaps attempt to create a diagram if that will help communicate the problem, this means a labelled network topology.

OpenBSD uses plain-text configuration files, we know nothing of their contents on your system.. post the output of at least your interface files, perhaps mygate if relevant and anything else that you deem significant.

Describe any changes you may have made to your systems recently that may be effecting things, either hardware or software.

Do you have any non-OpenBSD systems that you've failed to mention? are they configured properly? have you eliminated that as a candidate?

You scared off jggimi, an long time member of this forum.. perhaps this will open your eyes to your communication deficiencies..

It is simply unfair to paint half of a picture and leave the rest of it up to our imaginations.