Author Topic: Problem with dropped packets at Zentyal 3.5  (Read 1297 times)

juanmas

  • Zen Apprentice
  • *
  • Posts: 19
  • Karma: +1/-0
    • View Profile
Problem with dropped packets at Zentyal 3.5
« on: July 09, 2014, 09:48:46 pm »
Hi everyone!

I have the following problem with Zentyal 3.5. The network is as shown:

<-------WAN-------> 192.168.1.2/24 [ZENTYAL] 10.1.2.4/16 <-------LAN------>10.1.3.2/16[ROUTER]10.2.0.1/16<-----SUBNET----->

The problem is that I can ping Zentyal from the 10.2.0.0/16 subnet and go to internet, etc. But I can't ping any pc on the Zentyal Subnet 10.1.2.0/16.

When I take a look to the logs I see that ipsec is discarding packet:

zentyal-firewall drop IN=eth2 OUT=eth2 SRC=10.1.2.10 DST=10.2.0.10 PROTO=ICMP MARK=0x1

There's only one rule at the firewall : permit any to any.

It looks like there's no way that a packet came in and out by the same interface. It's what it looks like. If I configure a route un my pc like this: route add 10.2.0.0/12 gw 10.1.3.2 then it works perfectly. That means the traffic is not going across Zentyal. :-\

Any idea?

StuartNaylor

  • Guest
Re: Problem with dropped packets at Zentyal 3.5
« Reply #1 on: July 09, 2014, 09:59:33 pm »
10.2.0.1/16 is an external network to zentyal.

As its not declared anywhere which is basically done on each nic being either internal or external.

I suppose you would have to accept any on that source IP.

It all depends on your network but you can another nic and also serve that subnet.

Guess even just set up a virtual IP on your current.


juanmas

  • Zen Apprentice
  • *
  • Posts: 19
  • Karma: +1/-0
    • View Profile
Re: Problem with dropped packets at Zentyal 3.5
« Reply #2 on: July 10, 2014, 09:58:17 am »
Thanks for answer!

I did it. I've accepted all traffic from that subnet with the same results. Behind that router there are many other subnets there's no way to put an interface on each!!

Anyway, when a packet came across 10.2.0.0/16 subnet it reach directly the host but the host must send the packet using its default gw (zentyal) and then, Zentyal should use its internal route table to send it to the router. But that never happens.

The returned packet came into the Zentyal at eth1 interface and must go out by the same interface. That's what is messing up Zentyal.

This issue happens in older Zentyal versions.