Re: [ossec-list] ossec client registration over firewalls

2018-06-22 Thread a . bichsel
Hi Dan

Your note pointed me in the right direction. I don't have the issue on a 
pfsense either. And of course it has nothing to do with the protocol, 
otherwise DNS wouldn't work either. This seems to be a problem with this 
specific site.

Thanks!

On Thursday, June 21, 2018 at 6:14:48 PM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, Jun 21, 2018 at 10:37 AM,  > 
> wrote: 
> > Hi all 
> > 
> > I'm trying to connect several ossec agents to an ossec server over the 
> > internet and without vpn tunnels. This means, IPs get transformed 
> because of 
> > NAT. This is not a problem for agent-to-server communication, since I 
> can 
> > register each agent with source ip "any" and all packets go to the same 
> > server. However, it seems that the server tries to respond to some of 
> the 
> > udp packets. 
> > 
> > Here an example on what I see with tcpdump on the firewall at the ossec 
> > server site: 
> > 
> > 15:54:57.839960 IP [PUBLIC-IP-CLIENT-SITE].50497 > 
> > [PUBLIC-IP-SERVER-SITE].1514: UDP, length 158 
> > 15:54:57.841374 IP [PUBLIC-IP-SERVER-SITE].1514 > 
> > [PUBLIC-IP-CLIENT-SITE].50497: UDP, length 73 
> > 
> > And that of course doesn't work since the firewall on the client side 
> has no 
> > existing sessions (since protocol is UDP) and even if I allow all 
> traffic 
> > from ossec server to any client, the firewall wouldn't know how to 
> translate 
> > the public IP back to the private since there is no corresponding 
> session. 
> > The obvious solution would be to use TCP but as I read in this mailing 
> list, 
> > you cannot use TCP for agent-to-server communication. Another solution 
> would 
> > be VPN, since I could work without NAT then. But for me this is not a 
> > solution, since some clients are labtops and change their locations and 
> I 
> > also don't want to install a vpn client on labtops since I have to keep 
> a 
> > very small footprint on the clients. 
> > 
> > I don't think this is a very special setup and I hope somebody has found 
> a 
> > solution to this? 
> > 
>
> That's very strange, my firewall (OpenBSD's pf) is able to keep state 
> on UDP "sessions." 
> I don't know the details of how it does so though. 
> The Virgil security folks are adding some support for a new 
> communication method that should help, but this doesn't do much for 
> you now. 
>
> > Thanks in advance! 
> > 
> > Andreas 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "ossec-list" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to ossec-list+...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ossec-list] ossec client registration over firewalls

2018-06-21 Thread dan (ddp)
On Thu, Jun 21, 2018 at 10:37 AM,   wrote:
> Hi all
>
> I'm trying to connect several ossec agents to an ossec server over the
> internet and without vpn tunnels. This means, IPs get transformed because of
> NAT. This is not a problem for agent-to-server communication, since I can
> register each agent with source ip "any" and all packets go to the same
> server. However, it seems that the server tries to respond to some of the
> udp packets.
>
> Here an example on what I see with tcpdump on the firewall at the ossec
> server site:
>
> 15:54:57.839960 IP [PUBLIC-IP-CLIENT-SITE].50497 >
> [PUBLIC-IP-SERVER-SITE].1514: UDP, length 158
> 15:54:57.841374 IP [PUBLIC-IP-SERVER-SITE].1514 >
> [PUBLIC-IP-CLIENT-SITE].50497: UDP, length 73
>
> And that of course doesn't work since the firewall on the client side has no
> existing sessions (since protocol is UDP) and even if I allow all traffic
> from ossec server to any client, the firewall wouldn't know how to translate
> the public IP back to the private since there is no corresponding session.
> The obvious solution would be to use TCP but as I read in this mailing list,
> you cannot use TCP for agent-to-server communication. Another solution would
> be VPN, since I could work without NAT then. But for me this is not a
> solution, since some clients are labtops and change their locations and I
> also don't want to install a vpn client on labtops since I have to keep a
> very small footprint on the clients.
>
> I don't think this is a very special setup and I hope somebody has found a
> solution to this?
>

That's very strange, my firewall (OpenBSD's pf) is able to keep state
on UDP "sessions."
I don't know the details of how it does so though.
The Virgil security folks are adding some support for a new
communication method that should help, but this doesn't do much for
you now.

> Thanks in advance!
>
> Andreas
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.