This might be a record for the longest single-person thread on this list :)
After some more testing, it appears that I overlooked one simple fact in
my last post:
Inserting firewall rules into the default group via the <shellcmd> in
the <system> block of config.xml is only a solution if you do not plan
on modifying ANY firewall rules via the web GUI afterwards.
Once you make a firewall rule change via the web GUI and click on
"accept changes", the rules in the default group are regenerated,
causing you to lose anything you specified via <shellcmd> tags in the
config.xml file.
A quick reboot re-applies the custom rules in the <shellcmd> tags, but
rebooting a client's firewall is not something I do, nor advocate doing
whenever a firewall rule is changed.
Manuel, not sure if you have seen this or my other posts regarding this
issue. I am curious to hear your thoughts. The whole thread between me,
myself and I is quoted below. :)
Thanks.
Bill Arlofski
waa dash m0n0wall at revpol dot com
William Arlofski wrote:
>
>
> Ok after a long day and many different attempts, we made our way around
> this issue (limitation?).
>
> The solution was to insert a rule before the default block rule by
> utilizing the <shellcmd> directive in the <system> block of the
> config.xml file.
>
> <shellcmd>echo @14 pass out quick from 192.168.1.0/24 to
> 192.168.100.16/28 keep state group 0 | ipf -f -</shellcmd>
>
> Even though there is a rule in the gui on the LAN interface that says
> allow all traffic, any protocol from 192.168.1.0/24 to anywhere on any
> port, packets from 192.168.1.0/24 to PPTP clients were still being
> blocked and logged by the default rule.
>
> The rule that m0n0 generates from this LAN rule in the gui looks like:
>
> @2 pass in quick from 192.168.1.0/24 to any keep state group 100
>
> Which puts the rule in group 100, and the packets should be passed.
>
> The rule added with the shellcmd above is put into the default group,
> before the default block all rule, and allows the packets to pass OUT on
> any interface.
>
> This gets packets past being blocked on their way OUT of the ng[1-16]
> PPTP interface(s) as they were in the log snip in the original post below.
>
> Thanks to GeekGOd in #m0n0wall for all the time and effort yesterday. I
> thank you and my client thanks you.
>
> Perhaps you would like to follow-up on what I have stated above? Any
> suggestions or future feature requests? :)
>
>
>
>
>
>
> William Arlofski wrote:
> |
> | Sorry for such a long post, but I can't find anything similar to my
> | problem in the list archives, and I can not think of a quicker way to
> | resolve this.
> |
> | I am having an issue allowing Internal workstations access to external
> | PPTP clients. The Internal workstations I am referring to are NOT on
> | M0n0wall's "LAN Network" but are on a separate, private network
> | connected to M0n0wall's "LAN Network" by a Linux Iptables Firewall.
> |
> | M0n0wall is blocking these Internal machines from connecting TO remote
> | PPTP clients, but is allowing clients on its "LAN network" to connect to
> | these very same PPTP clients.
> |
> | Below is an ASCII art drawing of the network in question, followed by
> | additional info. Any help would be appreciated.
> |
> |
> | http://www.revpol.com/pptp.html
> |
> | - All networks are /24
> |
> | - There is an additional (not shown) 192.168.2.0/24 LAN routed
> | separately, but not relevant to this problem.
> |
> | - M0n0wall LAN IP is 192.168.100.2
> |
> | - PPTP clients are 192.168.100.16-30/28
> |
> | - PPTP clients have been allowed - via very restrictive rules on the
> | Linux Iptables firewall server - access to specific internal servers, on
> | specific ports. This works as expected.
> |
> | - Customer also wants VNC access (port 5900-5902) to connected PPTP
> | clients from Internal workstation on 192.168.1.0/24 network.
> |
> | - Rules to allow 192.168.1.0/24 to access PPTP clients on ports
> | 5900-5902 are in place on Linux IPtables firewall and on M0n0wall.
> | Actually, for testing purposes there are rules to allow ALL traffic from
> | 192.168.1.0/24 and 192.168.2.0/24 to m0n0.
> |
> | - VNC packets from internal workstation (192.168.1.9) are properly being
> | passed by the IPtables firewall, and are hitting the M0n0wall box but
> | are being blocked by M0n0wall's @0:16 default block rule. Here is a snip
> | from remote syslog server:
> |
> | Jan 10 21:31:55 192.168.100.2 ipmon[78]: 21:31:55.083569 ng1 @0:16 b
> | 192.168.1.9,33161 -> 192.168.100.16,5900 PR tcp len 20 60 -S OUT
> |
> | Here are the group 0 rules from status.php on the M0n0wall:
> | (BTW, I prefer my WAN interface to be number "0" so sis0 is WAN and sis1
> | is LAN)
> |
> | @1 pass out quick on lo0 from any to any
> | @2 pass out quick on sis1 proto udp from 192.168.100.2/32 port = 67 to
> | any port = 68
> | @3 pass out quick on sis1 from 192.168.100.0/24 to 192.168.1.0/24
> | @4 pass out quick on sis1 from 192.168.1.0/24 to 192.168.100.0/24
> | @5 pass out quick on sis1 from 192.168.100.0/24 to 192.168.2.0/24
> | @6 pass out quick on sis1 from 192.168.2.0/24 to 192.168.100.0/24
> | @7 pass out quick on sis0 proto udp from any port = 68 to any port = 67
> | @8 pass out quick on sis0 proto udp from MonoWanIP/32 port = 500 to any
> | @9 pass out quick on sis0 proto esp from MonoWanIP/32 to any
> | @10 pass out quick on sis0 proto ah from MonoWanIP/32 to any
> | @11 pass out quick on sis1 proto udp from 192.168.100.2/32 port = 500 to
> | any
> | @12 pass out quick on sis1 proto esp from 192.168.100.2/32 to any
> | @13 pass out quick on sis1 proto ah from 192.168.100.2/32 to any
> | @14 pass out quick on sis1 from any to any keep state
> | @15 pass out quick on sis0 from any to any keep state
> | @16 block out log quick from any to any
> |
> | - VNC from test client on 192.168.100/24 LAN to PPTP clients works as
> | expected.
> |
> | If any additional information is rewquired, please ask. I'd like to
> | either resolve this or tell my client that it is not possible.
> |
> |
> | Thanks in advance.
> |
> |
> | Bill Arlofski
>
>
>
>
>
> --
> Bill Arlofski
> waa dash m0n0wall at revpol dot com
| 