Inconsistant pinging across OPT (again but different)
-
yeah you sent them.. So validate its the right mac.. But like I said screams device, either the device has a firewall.. or isn't using pfsense opt IP as its gateway and is sending its response somewhere else.
Sniff on the device - does it get these request? Does it answer sending somewhere else? Wrong mask on the device and it thinks that is local so doesn't send answer back to pfsense.
maybe you have /16 vs /24 for its mask?
This server is multihomed?? Just noticed that - yeah that is going to be problematic for sure!! That is going to be asymmetrical nightmare.. Why do you users insist on doing such nonsense..
What is this devices default gateway?
So this device has legs in 2 different networks that route on pfsense.. If it trys and send its answer to a different interface of pfsense than it got the traffic on. Pfsense is not going to send that on, etc.
-
If the device sends a responed it will send it to the OP1 interface address appropriately to its route for 192.168.1.40.
Since pfSense has no state on LAN for the response packets, it will drop theme. -
@johnpoz I checked MAC & mask, they are all correct. I have some capture information I'll post separately, but I'm happy to discuss design decisions if that will fix the problem.
I am treating this Linux box as a sort of web server to run a bunch of self hosted stuff, and will be exposing it to the internet. The motivation for 2 ports was to have 1 on DMZ with access to internet and another port on a separate network for administration. I was under the impression that this was not unusual?
I'd be happy to discuss more either here or PM if you want to convince me this is a terrible idea ;)
-
@johnpoz as promised, the tcpdump from pinging. It looks like you're on the right path, the multihome seems to be causing some routing issues. AS you can see, it seems to eventually start to sort itself out, but even then I still see 0 packets from the tx side
-
@viragomann said in Inconsistant pinging across OPT (again but different):
Since pfSense has no state on LAN for the response packets, it will drop theme.
Not sure I follow, the TX packet coming from LAN hits "allow all" on the LAN firewall and is allowed through. This packet creates a "state" so the response will be allowed. What am I missing?
-
@coatmaker618 said in Inconsistant pinging across OPT (again but different):
nd will be exposing it to the internet.
That is the WORSE case scenario to multihome.. If the box was compromised - it would have direct access to any network it directly attached too, without having to go through firewall.
-
@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 :)
