Inconsistant pinging across OPT (again but different)
-
@coatmaker618
I meant, response will go back on OP1.
I correct it above. -
@johnpoz the other network would also be isolated too. It would NOT be a shortcut to the LAN or NAS or other private stuff. However I see your point. The goal of all this redesign I'm working on was to get stuff like this off the trusted LAN!! But it seems I'm taking that separation too far with multiple interfaces?
So your approach would be a single interface on DMZ for this server and just add a rule to LAN to say "allow ssh" & other debug stuff?
-
@viragomann that would certainly be a problem if Linux decided to respond over the default interface rather than the interface which received the packet.
That seems like a bad plan to me, but it would seem that perhaps that's what happening?
Also, sorry for the delay in response viragomann . Apparently I'm still too sketchy (not enough reputation) to post more than once every 2 minutes
-
@coatmaker618 said in Inconsistant pinging across OPT (again but different):
So your approach would be a single interface on DMZ for this server and just add a rule to LAN to say "allow ssh" & other debug stuff?
Yes.. what you would do is pinhole access from stuff in your dmz into your lan.. But why would dmz need access to ssh to something in trusted vlan? I can see trusted to dmz.. But stuff dmz should have access to should really be very limited.
My dmz has zero access into any of my other vlans.. you could make the argument that dmz stuff doesn't even have access to your local dns.. Why would dmz need to initiate traffic to any of your local stuff... Local stuff too dmz sure.. If your going to run some service it needs access to - think about putting that resource in the dmz as well. Or yeah a pinhole into another isolated vlan for say sql access or something.
-
@johnpoz my bad, I meant ssh FROM LAN to DMZ.
My network will eventually have several DMZ, and sure, some of them will have limited connectivity (eg: access a database over SQL or mounted drives from a NAS)--but no. The goal is to have LAN be the only "trusted" network, so the only source for ssh (or RDP, or VNC, or whatever, for debugging).
And certainly no DMZ will be able to reach INTO the LAN!
-
@johnpoz I've tried not allowing DNS for DMZ, but I find that web access & DNS is essential for updating services. Anything exposed to the web, be in Linux or a web service, should be kept up to date, no?
How do you keep OSes & services & such up to date on your DMZ without DNS? If there's a good approach, I may use this myself!
-
well you would have to point to dns, just external like googledns, or cloudflare.. I am talking about internal dns so if the box was compromised they wouldn't even be able to resolve your internal hosts on other vlans, and couldn't take down your local dns..
-
@johnpoz OH!
I gotcha! That's an interesting approach, you just have PFSense forward the DNS? I've never played around with that.
-
No not forward.. You would set say 8.8.8.8 for dns on the device in the dmz, and just allow that.. And block it from even talking to pfsense IP on 53..
If your box in the dmz can not talk to anything on the rest of your network on its own - why would it need to resolve any of your local stuff by name ;)
-
@johnpoz gotcha, that makes sense! Interesting point :)
-
ok, can someone remind me how to change the name of the topic...since I'm writing it off as solved at this point.
- It seems PFSense is indeed passing the communication along
- So it's an issue with the host having multiple active interfaces. The answer seems to be "stop it"
-
just edit your first post, and you should be able to edit it and even add tag as solved
If need be I can do it for you.
-
@johnpoz Got it, thanks :)
