Masaru Nomiya wrote:

Hello, In the Message; Subject : How to setup my network? Message-ID : 168871355810.3809.7792001584785391320@mailman3.infra.opensuse.org Date & Time: Fri, 07 Jul 2023 07:05:58 -0000 [MC] == Marc Chamberlin via openSUSE Users users@lists.opensuse.org has written: MC> Hello OpenSuSE, I have been trying/experimenting with setting up MC> my SOHO network of about 5 computers, most of which are running MC> OpenSuSE 15.4 x64, and one (my main gateway computer to the MC> internet) running OpenSuSE 15.3 x64. All systems are using the MC> Plasma/KDE desktop. My main gateway computer is called "quasar" MC> and the other systems have names such as "bigbang", "nova", MC> etc... MC> My network is split into 2 halves, 192.168.10.0/25 is my MC> "internal" zone, and 192.168.10.128/25 is my "dmz" zone. Except MC> for "quasar" each computer has 2 NIC's, one for each of my MC> zones. Addresses and default routes are assigned by a dhcpd MC> server, and that much is working fine (AFAIK) at the moment. MC> "Quasar" has 3 NIC's, one of which is for my "external" zone, and MC> the other two are for my "internal" and "dmz" zones MC> respectively. The "internal" zone NIC is given a static IP MC> address of 192.168.10.100 and the "dmz" zone NIC is given a MC> static IP address of 192.168.10.200. MC> My "external" zone NIC has been assigned 5 different public IP4 MC> addresses, all statically assigned by using the YaST2->Network MC> Card Setup to assign one of these public IP4 addresses to the NIC MC> card itself, and the other 4 public IP4 addresses are assigned to MC> this same "external" NIC card as additional addresses for that MC> "external" NIC card. MC> What I want to accomplish is to set up the routing so that any MC> incoming traffic to one of these external additional IP4 MC> addresses, on a port, gets routed from "quasar" to one of my MC> other computers on the DMZ side of my network on the same port MC> number. So for example, lets say there is incoming traffic whose MC> destination is 111.111.111.112:10. I want this to be MC> routed/forwarded to my internal computer called "Nova" at it's MC> DMZ address of say 192.168.10.210:10 and I don't want to specify MC> a rule for each and every port number specifically. Different MC> computers will have different services listening on different MC> ports. MC> How do I accomplish this? So far I have tried lots of MC> combinations of setting up rich and direct rules in firewalld, MC> using firewalld's port forwarding rules, using the route tables MC> in Yast2 -> Network Setup, and trying to write iptables rules MC> directly. I have turned on masquerading of course or used MC> nat/dnat rules in iptables. This seems like it should be fairly MC> straight-forward, but I have found no joy getting this to MC> work. (and have spent many days trying to grok a solution) I MC> would sure appreciate it if any guru here could show me how to MC> accomplish this wretched task before I pull all my hair out! One MC> caveat, it would be extremely difficult for me to run extra MC> cables and I really really want to accomplish this virtually with MC> only software configuration solutions. Sorry， just for testing． ChatGPT replies: You can use the iptables command to forward traffic from one IP address to another IP addresYou can use the iptables command to forward traffic from one IP address to another IP address on the same port in OpenSUSE. Here is an example command that forwards incoming traffic on port 10 from IP address 111.111.111.112 to IP address 192.168.10.210 on the same port: iptables -t nat -A PREROUTING -d 111.111.111.112 -p tcp --dport 10 -j DNAT --to-destination 192.168.10.210:10

Many thanks Masaru Nomiya and ChatGPT for your replies, I much appreciate your taking the time to write. I think I have already tried your suggestion but without defining port numbers. Specifying port numbers explicitly would require a lot of definitions and I don't want to maintain a large list of routing definitions for my entire network. I will show the list of rules I have currently configured, on my gateway computer called "quasar", to route from my external (public) IP address to one of my internal systems called "nova". eth0:novaExt is one of the additional public IP address on "quasar" that I added to quasar's external NIC. 192.168.10.210 is the address of the NIC on "nova" for it's DMZ interface. marc@quasar:/etc> firewall-cmd --direct --get-all-rules ipv4 nat PREROUTING 2 -d 111.111.111.112 -i eth0:novaExt -j DNAT --to-destination 192.168.10.210 ipv4 nat POSTROUTING 32 -s 192.168.10.210 -j SNAT --to-source 111.111.111.112 ipv4 filter FORWARD 22 -d 192.168.10.210/32 -j ACCEPT Keep in mind this is just my latest "creative" attempt at getting the firewall rules to work as I want them to do. This does not work however so I was a bit reluctant to show my current setup because I think it may confuse the discussion.

This command adds a rule to the NAT table that matches incoming traffic with a destination IP address of 111.111.111.112 and a destination port of 10, and forwards it to the IP address 192.168.10.210 on the same port. You can also use the following command to enable IP forwarding on your gateway computer “quasar”: echo 1 > /proc/sys/net/ipv4/ip_forward

Yes, I have already done this.

This command enables IP forwarding in the kernel, which allows your gateway computer to forward packets between different network interfaces.s on the same port in OpenSUSE. Here is an example command that forwards incoming traffic on port 10 from IP address 111.111.111.112 to IP address 192.168.10.210 on the same port:

iptables -t nat -A PREROUTING -d 111.111.111.112 -p tcp --dport 10 -j DNAT --to-destination 192.168.10.210:10 This command adds a rule to the NAT table that matches incoming traffic with a destination IP address of 111.111.111.112 and a destination port of 10, and forwards it to the IP address 192.168.10.210 on the same port. You can also use the following command to enable IP forwarding on your gateway computer “quasar”:

echo 1 > /proc/sys/net/ipv4/ip_forward This command enables IP forwarding in the kernel, which allows your gateway computer to forward packets between different network interfaces. How about this answer?

I am looking for a solution that doesn't require defining ports. I simply want all activity, on any port of Quasar's External interface for eth0:novaExt, to be forwarded to Nova's DMZ interface NIC, as is... Marc....

Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Hassabis says that no one really knows for sure that AI will become a major danger. But he is certain that if progress continues at its current pace, there isn’t much time to develop safeguards. "I can see the kinds of things we're building into the Gemini series right, and we have no reason to believe that they won't work," he says." -- "Google DeepMind's CEO Says Its Next Algorithm Will Eclipse ChatGPT" --

Andrei - yes I have been poking at this this and other possibly related problems for awhile now, trying to learn, looking at different symptoms not knowing if they are related or not, taking educated guesses on what I should address first, etc. So yes it has been a struggle working on multiple fronts and I think I have encountered your thoughts before, along the way. Can you show me how to use policies and how they could be applied towards the solution I am looking for. I don't understand them yet, and from what I have read it doesn't sound like policies are really ready for prime time. Only parts of them are implemented, according to some Googling I have done. As they say, a picture/example(s) would be worth a thousand words! Thanks again as always for your thoughts, Marc...

Andrei Borzenkov wrote:

On 09.07.2023 00:04, Marc Chamberlin via openSUSE Users wrote:

...

Andrei - yes I have been poking at this this and other possibly related problems for awhile now, trying to learn, looking at different symptoms not knowing if they are related or not, taking educated guesses on what I should address first, etc. So yes it has been a struggle working on multiple fronts and I think I have encountered your thoughts before, along the way. Can you show me how to use policies and how they could be applied towards the solution I am looking for. https://firewalld.org/2020/09/policy-objects-introduction

Thanks again Andrei for your help. Yes I have read this article and others as well about policy objects. To be frankly honest, I don't grok the difference between policies and forwarding/port forwarding rules. I will keep reading and searching for a better/more complete explanation.

...

In the current firewalld there are nothing but policies - all zone definitions are internally translated into policy definitions.

OK... I am not sure how this helps me and like I said, I am still confused about policies and their purpose.

...

Of course Leap 15.3 is using rather old firewalld so YMMV.

I plan to upgrade my one remaining Leap 15.3 system to 15.4 soon. There are some other hiccups I need to solve first before doing so, however. Marc...

Andrei Borzenkov wrote:

On 08.07.2023 00:21, Marc Chamberlin via openSUSE Users wrote:

...

ipv4 nat PREROUTING 2 -d 111.111.111.112 -i eth0:novaExt -j DNAT --to-destination 192.168.10.210 Interface "eth0:novaExt" does not exist so this rule will never match.

Andrei - You have lost me here, what do you mean "eth0:novaExt" does not exist? I created this interface with YaST2->System->Network Settings->Overview tab->Edit eth0->Address tab->Additional Addresses->Add and filled in the popup dialog fields for "Address label", "IP Address", and "Subnet Mask". Doesn't YaST2 set this up as an additional interface using the "Address label" name I gave it, which in this case was "novaExt"? The derived name for this interface then became "eth0:novaExt". I can certainly ping it and do other network tasks via this interface label. So in many ways, at least, this label for a network interface does feel like it exists! Thanks again, Marc...

Bob, Ken, again thanks for your thoughts and input. Ok, so as Shakespeare put is so elegantly, "What's in a name..." Let's stop using the term DMZ for the name of my second zone, and use "InternalDirectFromToExternal" I know how to create this zone name. All I did really was to use "DMZ" because it was already available and seemed closest to what I am trying to accomplish. Sorry for the confusion.... Marc...

Bob Rogers wrote:

From: Marc Chamberlin via openSUSE Users users@lists.opensuse.org Date: Sun, 09 Jul 2023 22:48:31 -0000 OK, so now you've renamed the zone for what it does (though a simpler, more rose-like, name might have served better).

LOL, OK how about IMZ for internal militarized zone? I am not clear why the network hawks chose to use a military term (DMZ) for describing a particular type of network design, but I really don't care about the name, just the functionality.

But I think we're all still a bit unclear on what you hope to accomplish by having a separate network for external traffic. If this traffic all goes to the same hosts anyway, what difference does it make? In terms of security, or ease of configuration, or anything else?

What I want is for each system to present a different set of capabilities depending on where the access to that system is coming from. For example the security cameras will require authentication if access to the computer that controls them comes from the internet via my IMZ zone. So I want to route all traffic that comes from the internet, destined to a particular public IP address, to be routed onto the IMZ zone and passed to the computer that controls my security camera. But if access comes from my internal zone, then no authentication will be necessary. Same goes for my computer that controls a telescope. I will want to be able to do things with the telescope (that potentially could damage the telescope, if mis-used), if I access it from my internal network (or from a VPN). If a guest accesses the telescope via a particular public IP address (that I own), that user will be routed via my IMZ zone to where he/she can access the telescope control computer via a different NIC and thus a different web interface that is more limited in capabilities. In other words, each of my computers will be "two-faced" and depending on how the computer is accessed, will determine which side of the computer's "faces" will be presented. Andrei seems to be implying that this particular use case is uncommon and possibly not easy to support. To me, as an object oriented designer/developer this type of usage of computers on a network seems to be an obvious one and should be easily supportable. HTHs, Marc...

From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 11 Jul 2023 01:52:04 +0200 On 2023-07-11 01:15, Marc Chamberlin via openSUSE Users wrote:

Bob Rogers wrote:

...

From: Marc Chamberlin via openSUSE Users users@lists.opensuse.org Date: Sun, 09 Jul 2023 22:48:31 -0000 OK, so now you've renamed the zone for what it does (though a simpler, more rose-like, name might have served better).

LOL, OK how about IMZ for internal militarized zone? I am not clear why the network hawks chose to use a military term (DMZ) for describing a particular type of network design, but I really don't care about the name, just the functionality.

For simplicity, we can just call them the "external" and "internal" networks.

...

But I think we're all still a bit unclear on what you hope to accomplish by having a separate network for external traffic. If this traffic all goes to the same hosts anyway, what difference does it make? In terms of security, or ease of configuration, or anything else?

What I want is for each system to present a different set of capabilities depending on where the access to that system is coming from. For example the security cameras will require authentication if access to the computer that controls them comes from the internet via my IMZ zone. So I want to route all traffic that comes from the internet, destined to a particular public IP address, to be routed onto the IMZ zone and passed to the computer that controls my security camera. But if access comes from my internal zone, then no authentication will be necessary.

Same goes for my computer that controls a telescope . . .

I suspect it is impossible to enforce. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar) Actually, I see three potential ways to accomplish this, albeit with limitations: 1. Given that you have said (in an earlier post) that you have two interfaces on each system, you can run two separate servers, one which binds only to the address(es) on the internal network interface, and another which binds only to the external interface addresses. The two separate servers can be configured independently, and there is no danger that the limited server will accidentally give too much privilege to external clients. Unfortunately, I suspect this won't work for your telescope, since I doubt you can share the hardware between two servers. 2. The conventional solution is to have a single server, and configure it so that it only grants higher levels of privilege to clients with addresses from the internal network. This requires just a single network with a single interface, but is more work to configure the server. And if the server doesn't let you classify users by IP address in its configuration interface, you're out of luck. 3. A hybrid solution would use one network and interface with two servers. The server for external users is configured as before, but it listens on a different port, chosen arbitrarily, and the firewall sends external connections to this port in order to leave the standard port free for internal network users. From the software (and security) point of view, this is exactly equivalent to the first option, but requires less hardware. Again, this doesn't work for non-shareable hardware. -- Bob

On Tue, Jul 11, 2023 at 2:15 AM Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> wrote:

In other words, each of my computers will be "two-faced" and depending on how the computer is accessed, will determine which side of the computer's "faces" will be presented. Andrei seems to be implying that this particular use case is uncommon and possibly not easy to support.

It is rather amazing how you put words in other people's mouths. We were discussing IP redirecting; you said "additional IP addresses on an interface are useless because they cannot be used in place of interface in iptables rules" and I replied that additional IP addresses are useful outside of iptables rules and can be matched in iptables rules as well. How you managed to draw the conclusion that I meant the overall design of your network I fail to grasp. And before you also claimed that I said that "the interface model isn't a well thought out consistent design, but just another example of a bad hack job" without any evidence. Really amazing. Anyway - the most obvious and easy solution to your "problem" is connecting your ISP uplink to the external switch and directly assigning external addresses on interfaces connected to this switch.

From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 11 Jul 2023 12:38:00 +0200 On 2023-07-11 08:49, Andrei Borzenkov wrote:

On Tue, Jul 11, 2023 at 2:15 AM Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> wrote:

...

Anyway - the most obvious and easy solution to your "problem" is connecting your ISP uplink to the external switch and directly assigning external addresses on interfaces connected to this switch.

Yes, this is what I said days ago :-) -- Cheers / Saludos, Carlos E. R. Ah, yes, your "morning tea" idea of 7-Jul; I had forgotten about that as well. That ought to make the configuration simpler, but would require Marc to acquire more public IP addresses from his ISP, and would probably therefore also require getting a commercial subscriber license, at a correspondingly higher commercial rate. -- Bob

From: "Carlos E. R." <robin.listas@telefonica.net> Date: Thu, 13 Jul 2023 11:31:45 +0200 On 2023-07-12 03:41, Bob Rogers wrote:

From: "Carlos E. R." <> Date: Tue, 11 Jul 2023 12:38:00 +0200

On 2023-07-11 08:49, Andrei Borzenkov wrote: > On Tue, Jul 11, 2023 at 2:15 AM Marc Chamberlin via openSUSE Users > <users@lists.opensuse.org> wrote:

...

> Anyway - the most obvious and easy solution to your "problem" is > connecting your ISP uplink to the external switch and directly > assigning external addresses on interfaces connected to this switch.

Yes, this is what I said days ago :-)

Ah, yes, your "morning tea" idea of 7-Jul; I had forgotten about that as well. That ought to make the configuration simpler, but would require Marc to acquire more public IP addresses from his ISP, and would probably therefore also require getting a commercial subscriber license, at a correspondingly higher commercial rate.

Why would he need more addresses? Because that's what "directly assigning external addresses" means, doesn't it? An external address has to come from the ISP. From your network diagram, it looks like you were talking about something different after all . . . -- Bob

From: "Carlos E. R." <robin.listas@telefonica.net> Date: Fri, 14 Jul 2023 13:01:15 +0200 On 2023-07-14 06:12, Bob Rogers wrote:

From: "Carlos E. R." <> Date: Thu, 13 Jul 2023 11:31:45 +0200

On 2023-07-12 03:41, Bob Rogers wrote: > > Ah, yes, your "morning tea" idea of 7-Jul; I had forgotten > about that as well. That ought to make the configuration > simpler, but would require Marc to acquire more public IP > addresses from his ISP . . .

Why would he need more addresses?

Because that's what "directly assigning external addresses" means, doesn't it? An external address has to come from the ISP. From your network diagram, it looks like you were talking about something different after all . . .

But he already has 5 public addresses, one per computer, since the start. It is in the OP mail. This is from the original post: From: Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> Date: Fri, 07 Jul 2023 07:05:58 -0000 . . . My network is split into 2 halves, 192.168.10.0/25 is my "internal" zone, and 192.168.10.128/25 is my "dmz" zone . . . Those both look like internal non-ISP address blocks to me. -- Bob

From: "Carlos E. R." <robin.listas@telefonica.net> Date: Sat, 15 Jul 2023 13:44:11 +0200 On 2023-07-15 00:44, Bob Rogers wrote:

. . .

Those both look like internal non-ISP address blocks to me.

You did not read the complete email, which is complicated to understand . . . OK, color me confused, then. This is an over complication, instead of simply assigning one external address to each computer and routing that, directly. Or switching. -- Cheers / Saludos, Carlos E. R. Amen to that. I think if I was going to go to the trouble of acquiring extra external addresses, I would have just set up a traditional sort of DMZ and called it a day. Then I would at least have the security benefit of isolation from my internal network. -- Bob

Andrei Borzenkov wrote:

On 09.07.2023 00:37, Marc Chamberlin via openSUSE Users wrote:

...

Andrei Borzenkov wrote: On 08.07.2023 00:21, Marc Chamberlin via openSUSE Users wrote: ipv4 nat PREROUTING 2 -d 111.111.111.112 -i eth0:novaExt -j DNAT --to-destination 192.168.10.210 Interface "eth0:novaExt" does not exist so this rule will never match. Andrei - You have lost me here, what do you mean "eth0:novaExt" does not exist? Show output of ip a

Thanks Andrei for helping me to understand what is going on with my network, much appreciate it. OK here is the output from "ip a" with my actual internet addresses obscured... 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/32 scope host lo valid_lft forever preferred_lft forever 2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:13:3b:2f:d4:66 brd ff:ff:ff:ff:ff:ff altname enp10s0 inet 192.168.10.100/25 brd 192.168.10.127 scope global p3p1 valid_lft forever preferred_lft forever 3: p3p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:13:3b:2f:d4:67 brd ff:ff:ff:ff:ff:ff altname enp11s0 inet 192.168.10.200/25 brd 192.168.10.255 scope global p3p2 valid_lft forever preferred_lft forever 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 98:90:96:e4:28:bd brd ff:ff:ff:ff:ff:ff altname enp0s25 inet 111.111.111.18/29 brd 111.111.111.23 scope global eth0 valid_lft forever preferred_lft forever inet 111.111.111.19/29 brd 111.111.111.23 scope global secondary eth0:bigbangExt valid_lft forever preferred_lft forever inet 111.111.111.20/29 brd 111.111.111.23 scope global secondary eth0:darkstarEx valid_lft forever preferred_lft forever inet 111.111.111.21/29 brd 111.111.111.23 scope global secondary eth0:novaExt valid_lft forever preferred_lft forever inet 111.111.111.22/29 brd 111.111.111.23 scope global secondary eth0:quasarExt valid_lft forever preferred_lft forever

...

I created this interface with YaST2->System->Network Settings->Overview tab->Edit eth0->Address tab->Additional Addresses->Add and filled in the popup dialog fields for "Address label", "IP Address", and "Subnet Mask". Doesn't YaST2 set this up as an additional interface using the "Address label" name I gave it, which in this case was "novaExt"? No. It adds an additional address to the interface eth0. Kernel does not create new interface in this case.

Why not? Why not have the Kernel simply create a new virtual interface? Or have YaST2/Firewalld create them for the Kernel to use? Are you implying that I need to add 4 NICs to my system, instead of just the one NIC I now have? If so, then I am not sure what value there is to adding additional addresses to an interface?

...

The derived name for this interface then became "eth0:novaExt". I can certainly ping it and do other network tasks via this interface label. So in many ways, at least, this label for a network interface does feel like it exists! Which does not make it the true real interface,

And now I am even more confused! What good is it to be able to give multiple IP addresses to an interface if one cannot use those addresses in a manner that is consistent with any other address? In object oriented design/programming if one builds an object and then extends that object with a child object then the child inherits all the capabilities of the parent. Why isn't this principal being applied to these so-called "fake" non-real IP addresses? Are you telling me that the interface model isn't a well thought out consistent design, but just another example of a bad hack job? I've never dug into the Linux kernel code myself, but from my experiences and all the hype about it, I thought it was designed using well thought out OO models that are consistent, maybe I am wrong? Anywise, I don't want to be told that I am simply doing things the wrong way nor argue about the design of Linux. If I cannot divine the way Linux interfaces work, then I really need examples of how to achieve my goal using the tools supplied by my distro. Thanks again for your thoughts, much appreciated! Marc...

Am 07.07.23 um 09:45 schrieb Adam Mizerski:

W dniu 7.07.2023 o 09:31, Marc Chamberlin via openSUSE Users pisze:

...

Oh, I thought of one additional requirement, if it is possible. I use port knocking to open ports to services. I would like port knocks to also be forwarded to my targeted "dmz" systems as well. This has been a real head scratchier for me also...   Marc...

I suggest using OpenWRT for this. It's a linux distro designed for routers, but you can also install it on x86 PC. It has a web ui, that allows to configure it all.

And before you actually reinstall your system, you can try to reproduce your environment with virtual machines and try there. Both VirtualBox and libvirtd are fine.

not forget virt-manager and qemu simoN -- www.becherer.de

Adam, Simon - Thanks for your suggestion to use a virtual machine to solve my issue with routing. I have no experience with installing and using virtual machines, and fear a steep learning curve may be required. I will keep your ideas in the back of my mind, for future reference in case I can't find a solution with existing tools in OpenSuSE. Hopefully I can find a solution that won't take a lot of time to implement. Marc...

Thanks Adam for your thought. Interesting idea, but kinda expensive. I would want to play with it to make sure it could meet my needs first before buying one. Will look further into it if I can't come of with an OpenSuSE solution. Marc...

Hi Carlos, and thanks for the suggestion of using a switch, but wouldn't this require me to install a cat5 cable from the switch to each of my computers? If so, that would require an incredibly difficult/perhaps impossible task for me to do so, and WiFi is not a solution either. I am hoping to find a way to do this with my existing cables. Marc...

On Fri, 07 Jul 2023 22:05:09 -0000 Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> wrote:

Hi Dave, and thanks for your input, much appreciated. Actually, each of my computers have a different purpose, one controls my radios and antennas in my ham radio shack, one controls a telescope, one controls my media center and security cameras, and a couple are general purpose workstations. I need to be able to differentiate how access to these computers is happening, if access is coming from my internal network then more rights and privileges to do things on that computer, being accesses, is granted. If access is coming from the internet then rights and privileges will be more restrictive. I don't have the luxury (or budget) to further split my computers so that they follow your "usual" arrangement of putting entire hosts in the DMZ separate from the hosts in my internal zone. And yes I understand the risks and do use additional security measures such as using encrypted data files to mitigate such issues.

Then your entire system is a waste of resources. Just use software to control access.

From: Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> Date: Sat, 08 Jul 2023 20:52:25 -0000 Dave Howorth wrote:

...

Then your entire system is a waste of resources. Just use software to control access.

Hmmm, Dave I don't understand your response or how you can come to a conclusion that my entire system is a waste of resources! . . . All you have done is throw my question back at me, told me to wave my hand and use software magic to control access. His point is that you do not seem to have set up your DMZ in the conventional way [1]. By allowing hosts on your DMZ to access the internal network (IIUC), you've eliminated the advantange of having a DMZ in the first place -- if someone hacks their way through the server, they've gained access to both networks. So if you want to restrict privileges to external users, you could discriminate at the server level based on external vs. internal IP addresses, and simplify your hardware configuration by eliminating the extra network. And my apologies if I've misunderstood what you want to do; I've only been half following this thread. -- Bob Rogers http://www.rgrjr.com/ [1] https://en.wikipedia.org/wiki/DMZ_(computing)