[SOLVED] Zentyal 4 firewall problem with dropping ip packets from local host

[idgi3]

Hello everyone!

I have server zentyal CE 4.0. eth0 watching local network, eth1 watching to internet via pppoe.
DHCP pool is 192.168.0.150 - 192.168.0.240.
I`m creating some groups of computers in Network objects, and than in DHCP service choose Static IP to that groups.
IP`s from 192.168.0.10 to 192.168.0.149.

In the local network i have 2 wifi antennas, one Access Point, other - Repeater.

Problem is: When i`m trying to use internet WiFi which Access Point - there is no problems, but when i use Repeater Firewall drops any IP packets to server.
If i dont use static IP adresses in DHCP - there is no problems.

When i see to syslog (attach)  i cant understand difference between the packets that ACCEPT or DROP.

I tought if my situation is GRE IP packets, so
modprobe ip_gre
iptables -A INPUT -p gre -j ACCEPT
iptables -A OUTPUT -p gre -j ACCEPT
- problems still here

Then i`ve tried to understand why firewall choose DROP or ACCEPT in some situations:
 sudo tcpdump -n -nn -ttt host 192.168.0.52 -w tcpdump.txt, so i have the message from tcpdump that 0 packets was dropped by kernel - how could this be?

Here firewall LOGs part
2014-11-25 16:14:28 eth0 ppp0 192.168.0.52 195.210.46.29 TCP 58125 80 DROP
2014-11-25 16:14:25 eth0 ppp0 192.168.0.52 198.41.215.184 TCP 57764 80 DROP
2014-11-25 16:14:07 eth0 192.168.0.52 192.168.0.52 UDP 67 68 DROP
2014-11-25 16:13:59 eth0 192.168.0.52 192.168.0.1 UDP 23979 53 DROP
2014-11-25 16:13:58 eth0 192.168.0.52 192.168.0.1 UDP 21866 53 DROP
2014-11-25 16:13:57 eth0 192.168.0.52 192.168.0.1 UDP 11131 53 DROP

when i use WiFi Access point Antenna, not repeater - i dont have any problem, also firewall workin fine if i dont choose static IP for my device.

What is the difference betwen UDP packet from local host (with static IPaddress) via WiFi Access Point and the UDP packet from same local host via WiFi Repeater?

Sorry for my English.

I would appreciate any help!

[jbahillo]

idrop      all  --  192.168.0.52         anywhere             MAC ! 8C:3A:E3:4C:46:F4


Might be the MAC address??

Please remember in addition that -A appends a rule (put it at the end) You perhaps might be interested in using -I (insert) which puts it at the top

[idgi3]

Thanx. I will try to change fnospoof and inospoof chains in iptables.

But I did not add any rules in iptable. After reboot GRE rules was deleted.

I think that chains "inospoof" and "fnospoof" were generated by Zentyal firewall after reserving IPs in DHCP.
So if i change this manually i will have same problem next time after reserving another IPs, didnt i ?

How can i switch off "nospoof" chains in Firewall?

[idgi3]

So. The problem probably solved... here is the tips http://www.vionblog.com/zentyal-3-2-pptp-server/

when i manually add
/sbin/iptables -t filter -A fnospoofmodules -s 192.168.0.52/32 -j faccept
/sbin/iptables -t filter -A inospoofmodules -s 192.168.0.52/32 -j iaccept

the problem has gone, and i have no drops from firewall.

But i cant understand how to use /etc/zentyal/hooks/template.postservice
1.
/sbin/iptables -t filter -A fnospoofmodules -s 192.168.0.52/32 -j faccept
/sbin/iptables -t filter -A inospoofmodules -s 192.168.0.52/32 -j iaccept
exit 0
2. sudo chmod +x /etc/zentyal/hooks/template.postservice
3. sudo service firewall restart

and i dont have those rules in inospoofmodules and fnospoofmodules...

[jbahillo]

Hello:

fnospoof and inospoof chains are created for security reasons to avoid somebody trying to spoof the IP for Forward (fnospoof) and INPUT (inospoof) traffic. MAC for any rule here are taken from any object you nay have created in Zentyal GUI

The only way to avoid this would be placing a rule ON TOP (so -I, not -A) which  of these iptables chains matching the traffic which is being dropped, and passed with an ACCEPT. Unfortunatelly antispoof rules cannot be disabled from GUI.


Regarding hooks, they are scripts which are run at a certain point of Zentyal module life. This being said, a postservice firewall hook will be run AFTER  (post) module firewall is restarted. This is needed because as you may know, Zentyal deletes any firewall rule on Firewall module restart, and generates and applies rules again.


BR

[idgi3]

yeah...

cp /etc/zentyal/hooks/template.postservice /etc/zentyal/hooks/firewall.postservice

and now i have no nospoof defence, but i dont have any problems with my Repeater WiFi antennas.

thanks jbahillo.

[idgi3]

Can anyone explain how the IP packet can return from this chain of iptables,

i see if MAC addres for host 192.168.0.52 not 8C:3A:E3:4C:46:F4 then idrop, but than all 192.168.0.0/24 idrop - how can it be?

Chain inospoof (1 references)
target     prot opt source               destination
inospoofmodules  all  --  anywhere             anywhere
idrop      all  --  192.168.0.52         anywhere             MAC ! 8C:3A:E3:4C:46:F4
idrop      all  --  192.168.0.0/24       anywhere


after all i do the host go to Internet without my squid, but in iptables -t nat i have:
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
premodules  all  --  anywhere             anywhere
DNAT       tcp  --  anywhere             8.16.32.64          tcp dpt:https to:192.168.0.2
DNAT       udp  --  anywhere             8.16.32.64          udp dpt:https to:192.168.0.2
DNAT       tcp  --  anywhere             8.16.32.64          tcp dpt:http to:192.168.0.2
DNAT       udp  --  anywhere             8.16.32.64          udp dpt:http to:192.168.0.2
DNAT       tcp  --  anywhere             8.16.32.64          tcp dpt:50500 to:192.168.0.2
DNAT       udp  --  anywhere             8.16.32.64          udp dpt:50500 to:192.168.0.2
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
postmodules  all  --  anywhere             anywhere
MASQUERADE  all  --  anywhere             anywhere
Chain postmodules (1 references)
target     prot opt source               destination
Chain premodules (1 references)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere            !server.qwert.yui    tcp dpt:http redir ports 3128

[jbahillo]

Hi:

Just check it with -v so you have interface information.

I'm sure that second idrop affects only when traffic comes from an interface which is not the one which handles that network


Regarding proxy, just place a new rule ABOVE (remember -I) on premodules  this one:
REDIRECT   tcp  --  anywhere            !server.qwert.yui    tcp dpt:http redir ports 3128

Something like this should be ok


iptables -t nat -I premodules -s Your-IP -p tcp -m tcp --dport 80 -j ACCEPT