route from one subnet to another

[lelik]

I set up ebox with 3 Nics:

eth0 = wired (internal) static 192.168.0.1
eth1 = internet (external) dhcp, ISP provided
eth2 = wireless (internal) static 192.168.1.1

Is it possible to add a route to the ebox to let computers connected to eth0 [192.168.0.0/24] "see" computers connected to eth2 [192.168.1.0/24]?
Do I have to add any firewall rules as well?

[alvinquah]

under network menu, there is a static route item. Use it to route between different subnet.

[lelik]

Added the route - still no go.
Should I add any special rules to /etc/ebox/hooks/firewall.postservice ?

[lelik]

No routing "experts"?

[Saturn2888]

From what I've seen, I have a 1.1.0.0 and 2.2.2.0 network and both intermingle, but they are both from the same adapter and one is a virtual adapter. Make sure your subnets are setup properly.

[EscArtist]

under network menu, there is a static route item. Use it to route between different subnet.

You don't need to add static route. Routes for 192.168.0.0/24 and 192.168.1.0/24 are already known to the eBox.

You clients should have the ebox address set as they default gateway.

You may need to configure your firewall I am not certain how eBox works in this setup as I don't have it installed so far.

[Saturn2888]

Well that's what we're talking about. It's doing this, we'd like it NOT to route between certain networks. Certain granularity in that network A can see B but not talk to it, B can see and talk both A and C, and C has no clue anyone else is there are great ways of securing a network.

[EscArtist]

Well that's what we're talking about. It's doing this, we'd like it NOT to route between certain networks. Certain granularity in that network A can see B but not talk to it, B can see and talk both A and C, and C has no clue anyone else is there are great ways of securing a network.

Actually lelik wrote:

Is it possible to add a route to the ebox to let computers connected to eth0 [192.168.0.0/24] "see" computers connected to eth2 [192.168.1.0/24]?

Can you give me better example about your situation with networks A, B and C. What does SEE and TALK mean?

If you are talking about filtering protocols (ICMP, TCP, UDP) then it's the firewall where this should be configured. It would be nice if some of the eBox people join this conversation to let us know where and how exactly can be done.

[Saturn2888]

That's what I mean. The firewall isn't able to change that. Right now, as long as it goes through the eBox, it's routeable by default. There's only differentiation between internal and external, not internal subnet A and internal subnet B.

[Sam Graf]

Is this the case for subnets on different physical interfaces?

[EscArtist]

Is this the case for subnets on different physical interfaces?

Yes.

[Sam Graf]

And it is not possible to allow or deny traffic between subnets via the firewall?

I use a firewall rule to allow HTTP traffic from a VPN subnet for remote groupware access, where the eBox VPN server is also running Squid, for example:

Rule - Accept
Source - VPN subnet/24
Destination - local LAN/24
Service - HTTP

so I am wondering if an ACCEPT/DENY rule would work for other services and types of subnets.

[EscArtist]

And it is not possible to allow or deny traffic between subnets via the firewall?

I use a firewall rule to allow HTTP traffic from a VPN subnet for remote groupware access, where the eBox VPN server is also running Squid, for example:

Rule - Accept
Source - VPN subnet/24
Destination - local LAN/24
Service - HTTP

so I am wondering if an ACCEPT/DENY rule would work for other services and types of subnets.

This was my first though too. It is not the same case but Saturn2888 said that this is not possible with two LAN subnets from two different internal network interfaces. I don't have a configuration at hand to be able to try this out, I believe it can be tested in VM as well.

Sam Graf, what do you have as advertised networks in your VPN setup? If you have the whole LAN subnet then I don't think you need that firewall rule.

[Sam Graf]

... what do you have as advertised networks in your VPN setup? If you have the whole LAN subnet then I don't think you need that firewall rule.

Yes, the entire local LAN is advertised, and others have also said this should be enough, but the server will accept no HTTP traffic. Attempts to access a web interface remotely just time out. I have both a groupware server and a NAS device on this particular LAN, and neither is accessible remotely via HTTP without the rule.

I was told the same thing about using the Jabber server privately in a VPN context, but there I must have a rule (I use Any/Any/XMPP) in "Filtering rules from internal networks to eBox" in order for remote Pidgin installations to access the server.

I dunno ...

[Saturn2888]

There's no an internal networks to internal networks in the firewall, and if there was, it better be more specific to each specific internal network and how that network interacts with the others. Probably would be good to use some sort of template or profile system as well so you can port over firewall rules much more easily.

VPN systems are a whole 'nother cat. There are absolutely no firewall rules in eBox as of 1.4.3 to apply to VPN. There are very many missing features for VPN in eBox so it's surprising it works. To get clients from the VPN to talk to clients on the advertised networks, I didn't have to do anything but add those networks to the Advertised Networks area in VPN. You should 100% be able to access the eBox and should have near to no trouble accessing advertised networks.

The problem comes up when you're on the inside accessing VPN'd machines. VPN'd machines can do client-to-client connections, but internal-to-client connections require putting this information in your usr/share/ebox/stubs/openvpn/openvpn.conf.mas file.

</%args>
% foreach my $net (@nets) {
%   my ($net, $netmask) = @{ $net  };
   push "route <% $net %> <% $netmask %>"
   push "dhcp-option GATEWAY 192.168.0.1"
   push "dhcp-option DNS 192.168.0.1"
   push "dhcp-option WINS 192.168.0.1"
   push "dhcp-option NBT 2"
   push "dhcp-option DOMAIN WORKGROUP"
%}
</%def>

I dunno about the GATEWAY one. I just added it today to see if it might work because it allows you to ping the machine from the inside I believe. Also note that for Windows machines, if they're on the VPN, you have to explicitly configure firewall rules for that network.