I have lost the concept completely

[calanon]

I know this that is probably the most basic question but my syntax just does work as I expected. First here is the syntax and then I will try to explain the result I want:

MGMT = "em2"
OPS = "em0"  ### OPS Network 10.11.0.0/16
DMZ = "em1"   ### DMZ Network 10.12.0.0/16
OPSUBNET = "10.11.0/16"
IT = "10.10.10.100"
ext_if = "em0"
icmp_types = "{ echoreq, unreach }"
mgmt_ports = "{ ssh, telnet }"

# Policies
set block-policy drop
set loginterface $ext_if
set skip on lo

# Tables

table <bruteforce> persist
block in quick from <bruteforce>

# default block
block return log

pass log from $OPS
pass log proto tcp to self port ssh 

pass in on $OPS inet proto tcp from $OPSUBNET to $OPS port $mgmt_ports
pass out on $OPS inet proto tcp to MGMT port $mgmt_ports
pass in on $MGMT inet proto tcp from $OPS to $MGMT port $mgmt_ports
pass out on $MGMT inet proto tcp to $IT port $mgmt_ports
pass log inet proto icmp all icmp-type $icmp_types keep state

10.11.0.10 ---------> SSH 10.11.0.11 via ($OPS em0) --------->10.10.10.1($MGMT em2)---------> $IT (10.10.10.100 Client)

10.10.10.100 ------> SSH via 10.10.10.1 ($MGMT em2)---------> ($DMZ em1)---------> Client Machine (10.12.0.10)

So I want to be able to ping from 10.11.0.10 and traceroute to 10.10.10.100, also to do the same in reverse order

I would like to be able to ssh into Client 10.10.10.100 from client 10.11.0.10

I would like to be able to ssh into Client 10.12.0.10 from client 10.10.10.100 and also ping it.

I just cant seem to figure out where I have gone wrong or what static routes I would need.

Please help? I would be eternally grateful

[jggimi]

Be VERY CAREFUL with the restriction directives from, to, in, out, and on. They don't necessarily mean what you think they mean. My specific comments are shown after each referenced code block.

set block-policy drop
.
.
block return log

Your block-policy is not in use.

pass log from $OPS

$OPS resolves to the interface em0. PF will convert "from interface" directives without modifiers to "from the assigned addresses for the interface." For example, if em0 is assigned the address 10.11.1.1, then this rule will be interpreted as "from 10.11.1.1" -- which I assume is not your intent. Interfaces can have modifiers, such as "em0:network", and while you could shoehorn that in as a solution, I believe your intent is to allow traffic in on em0, rather than from em0.

pass in on $OPS inet proto tcp from $OPSUBNET to $OPS port $mgmt_ports

This is odd for two reasons.

1. Two systems on the $OPS subnet can communicate with each other without involving this system. So "in on $OPS" combined with "to $OPS" isn't going to match any inbound traffic unless the destination address is an assigned address for the interface em0.
2. If $OPS is a single-router endpoint network, then $OPSUBNET is unneeded, as all traffic from em2 will have a 10.11/16 source address anyway.

pass out on $OPS inet proto tcp to MGMT port $mgmt_ports

Here, you pass out on interface em0 your traffic which is actually destined for em2.

At this point, I think I'll suggest you draw a picture of your physical topography. As I think I recommended in your last several PF threads.

[calanon]

OPSNETWORK ———————|. |—————— DMZNETWORK
10.11/16 | | 10.12./16
em0 em2
| |
BSDROUTER
|
em1
|
|
MGMGTNETWORK
10.10/16

SSH FROM OPSNETWORK TO MGMTNETWORK
SSH FROM MGMTNETWORK TO DMZNETWORK
HTTPS ONLY FROM DMZNETWORK TO MGMTNETWORK
PING FROM OPSNETWORK TO IP ON em0
PING FROM MGMTNETWORK TO ANY ON DMZ AND OPSNETWORK

I hope this clarifies it?

[calanon]

Here is an image of the network as attachment

[jggimi]

Here is a ruleset based on your graphic. Note that there is no "Internet" connection defined, nor is there any domain traffic permitted. What ICMP traffic is permitted is ping, only, and limited as you directed.

ops = "10.11/16"
dmz = "10.12/16"
mgt = "10.10/16"

# default block

block return log

# ssh:
# from ops to mgt
# from mgt to dmz

pass log proto tcp from $ops to $mgt port ssh
pass log proto tcp from $mgt to $dmz port ssh

# https:
# from dmz to mgt

pass log proto tcp from $dmz to $mgt port https

# ping:
# from ops to the address(es) defined for em0
# from mgt to dmz and ops

pass log proto icmp from $ops to em0 icmp-type echoreq
pass log proto icmp from $mgt to { $dmz $ops } icmp-type echoreq

[calanon]

Unfortunately it worked perfectly 😉😉😉 thank you so much

[jggimi]

I kept it simple.

I limited restriction directives to from and to. The single use of an interface is translated to its IPv4 address or addresses assigned by your /etc/hostname.em0 file.

[calanon]

Originally Posted by jggimi

I kept it simple.

I limited restriction directives to from and to. The single use of an interface is translated to its IPv4 address or addresses assigned by your /etc/hostname.em0 file.

Sorry to bring this one up again but I am having difficulty with the rules you gave below:

pass log proto tcp from $ops to $mgt port ssh
pass log proto tcp from $mgt to $dmz port ssh

When I try to SSH from the client machine on the $mgt network through to the $dmz network and eventually to $dmz_ops network this rule does not work. The $dmz_ops network is on a different router/bsd box. If I explicitly state pass in on and pass out on the interface it works.

[jggimi]

Originally Posted by calanon

When I try to SSH from the client machine on the $mgt network through to the $dmz network and eventually to $dmz_ops network this rule does not work.

I don't understand. Probably because "$dmz_ops" is not defined in this thread.

[calanon]

Originally Posted by jggimi

I don't understand. Probably because "$dmz_ops" is not defined in this thread.

So the rules above are defined in one bsdrouter. There is another bsdrouter doing something similar. The $dmz_ops is the egress on the other router. I hope that makes sense?

[jggimi]

Originally Posted by calanon

I hope that makes sense?

Not as written.

You have confused me, because you are reporting a problem that is out-of-scope for the problem set you defined for this thread.

I also don't know if this new complaint is related to your ssh "block" problem you also reported here today, or if that problem is related to the scope previously defined in this thread.

I can only work with what YOU choose to provide. My crystal ball is broken.

[calanon]

Originally Posted by jggimi

Not as written.

You have confused me, because you are reporting a problem that is out-of-scope for the problem set you defined for this thread.

I also don't know if this new complaint is related to your ssh "block" problem you also reported here today, or if that problem is related to the scope previously defined in this thread.

I can only work with what YOU choose to provide. My crystal ball is broken.

Okay I am really sorry, let me try to express the problem only in this thread. The other thread issue can wait for the moment.

I have attached an image that I hope makes sense.

[jggimi]

I have had the opportunity to review the new graphic.

As I perceive it, your new subnet "$dmz_ops" has introduced a routing problem, because the subnet address (192.168.15/24) is not within the larger $dmz subnetwork (10.12/16). I believe there may be three ways to manage this new subnet. In recommended order:

1. Use a subnet within the larger 10.12/16 $dmz address space.
2. Add a route in Router 1 to the new $dmz_ops subnet through Router 2. Add a similar route in any device in $mgt or $ops that needs access to $dmz_ops to direct that traffic through Router 1.
3. Configure Network Address Translation (NAT) and appropriate TCP/UDP port forwarding as needed in order to reach the $dmz_ops platforms.

I may try to recreate this pictorial in virtual machines as time permits later this week.

[jggimi]

I had some time this evening to replicate the environment. Two routers, 4 subnets, and terminal workstations/servers on all 4 networks. I used your addressing schema, and did not test https or NAT. Pings and ssh sessions were the extent of my tests.

I was able to establish ssh sessions from the $mgt network to the new $dmz_ops network via adding the following lines to the pf.conf I posted earlier in this thread, using it in Router 1.

.
.
dmz_ops = "192.168.15/24"
.
.
pass log proto tcp from $mgt to $dmz_ops port ssh
.
.

The pf.conf(5) file in Router 2 was the default file from 6.6-release.

Router 1 requires a static route(8) for the $dmz_ops subnet. As an example, the hostname.if(5) file on Router 1 that defined the $dmz subnet contains:

10.12.0.1/16
!route add 192.168.15.0/24 10.12.0.2

Any devices that do not use Router 1 as their default/gateway route will need a similar static route added to reach the $dmz_ops subnet.

[calanon]

Thank you for your time. This seems to work as intended. Just need to get the NAT working now

[jggimi]

If the $dmz_ops subnet is used without NAT:

• A static route pointing to Router 2 is needed in Router 1, as I mentioned above.
• Any other devices on the $dmz subnet will need a static route to Router 2 in order to communicate with $dmz_ops addresses.
• Any devices *outside* of Router 1 that do not use Router 1 as their default router (gateway) , will need a static route to Router 1.

NAT can be used to reduce routing requirements, but it adds its own complexities. Using your most recent graphic as a simple example, you have two systems you might wish to reach with SSH: the server at 192.168.15.15, and Router 2. You'll need two destination port numbers, one for each of these systems, and you'll need to decide on the numbers and decide which is forwarded. Users trying to reach the SSH servers would need to know the destination port numbers, since both servers would appear to be using address 10.12.0.2.

Add that decision and provisioning again for every device you might add to the $dmz_ops subnet.

---

If you're interested in alternative topologies, a tiered-DMZ solution often looks something like this:

{Internet} - [FW1] - DMZ - [FW2] - {Local intranet}

FW1 blocks external inbound traffic from reaching FW2. FW2 only permits select, expected traffic from DMZ servers into specific local systems, such as permitting only SQL queries from a specific DMZ application server to reach its back-end database server.

The local intranet is often further subdivided into subnets-by-service, such as database servers, internal-facing servers, workstations and VOIP, and backup. Each can have a similar tiered DMZ in place.