Hello,
> yeah that's about right for VM.
Well they are designed for the non-tech savvy individual, they are just
plug and play. A&A give you an entire control panel to mess with (and
trust me I messed with it :P) and has the option of providing your own
router, which I did of course :)
>
> You posted netstat -rnfinet from before making changes and not the others.
> Seeing the whole lot together, in the form of files from the machine
> itself not a description, often makes it easier to understand what's
> going on.
Ah yes, when I didn't do the subnet properly (take 1 off either end of
the subnet).
Completely forgot about that, sorry for making a stupid comment then.
> Here you run into a problem that's introduced by the unusual "two L3
> networks on a shared L2 network" setup - you're natting 192.168.2.0/24
> *and* 217.169.18.56/29. Should be 192.168.2.0/24 not $lan:network.
Ah I completely forgot to check the older rules, because for the IPv4
NAT I followed the man pages originally I never did any conditions.
I guess this is one of the major reasons Zack discouraged L3 (IP) rules,
and recommended using interfaces.
> If there's a mistake that would result in the behaviour you mentioned,
> it would most likely be in this section.
Yes I believe it could, let me stick one of the non-personal rules in
for lets say my email container (which hosts this email coincidentally
enough):
# Email - TCP
# Port 993 - imaps (secure imap)
# Port 587 - smtp submission
# Port 25 - smtp relay
pass in on $wan proto tcp from any to any port {993 587 25} rdr-to $email
pass in on $lan proto tcp from 192.168.2.0/24 to $nataddr port {993 587
25} rdr-to $email
For the second rule you can see I had thought about the static block
back when port forwarding, but I wrote these forward rules ages ago, and
I completely forgot that if I do from any to any it would include the
/29 block.
So I believe you are correct and this is the problem, it should be from
any to $nataddr.
However on the other hand:
pass in quick on $wan inet from $staticv4b1 to any keep state
pass in quick on $lan inet from $staticv4b1 to any keep state
pass out quick on $lan inet from any to $staticv4b1 keep state
pass out quick on $wan inet from $staticv4b1 to any keep state
Shouldn't quick pass it out immediately and forget all the other rules?
or have I misunderstood the use case for quick?
How I saw it used was to ensure rules you wanted to be done "quickly"
say drop all packets on 192.168.56.0/24, would be done and then ignore
the other rules, but I guess I misunderstood here.
I will try fixing this, and give my response in a follow up email
because I can't change it right now and will need to later.
>
> I tend to ignore comments when debugging rulesets because they can
> mislead. They're useful for seeing the intent, but if the comment
> doesn't match what the config actually does, it's too easy to trust the
> comment.
Understandable, who knows, I might have wrote a rule which I thought did
one thing and did something completely different xD
As a note I should really strip all sensitive information from a
plaintext configuration, I just got lazy and it was the simplest way to
identify the rules.
Thank you for pointing out the issues in my pf.conf, I will see if
correcting them fixes the problem, and thank you for all the help as a
whole.
Have a good day,
--
Polarian
GPG signature: 0770E5312238C760
Website: https://polarian.dev
JID/XMPP: polarian@polarian.dev
No comments:
Post a Comment