Big network...

amazingly it started working. BUT is there something I can do to prevent this? its been not working for over an hour then poof it started working. This CANNOT happen.

Ok I got it to not work again. and here is how I did it.

We have 4 networks off the astaro.

192.168.1.0/24
192.1.3.0/24
10.10.0.0/22
10.10.4.0/24

When I used terminal serverices to get from 192.1.3.0/24 to 10.10.0.0/22, all pings and surf ability stopped on the machine that is on 10.10.3.0.

Well I keep making progress. Here is what is happening. Everything works fine, then when I terminaled into another server on another network through the astaro anything on 10.10.3.0 stopped. I checked the arp cache and on the machine on 10.10.3.0 the mac listing for the astaro is WRONG!! the server on 10.10.0.0 that still worked had it as the correct mac. Some how the mac address are being mixed. WTF!

So I did an arp -s and statically assigned the astaro in my arp table. everything works. Anything astaro is doing to correct this? or is just the complexity of the network? For now we are going to add the arp -s into the log inscripts so no one has a problem. Man this topic is a one man show!!!

Weird problem. Make sure you log an Astaro trouble ticket so they know about it!

Hi Mitch, 

how many Interfaces does your system have?

How do you interface configuration look like?

Which advanced features do you have enabled?
- Packet Filter > Advanced > Spoof Protection
- Packet Filter > Advanced > Strict TCP Session Handling
- IPS > DoS/Flood Protection
- IPS > Flood Protetion

Do you have configured any routes (static, policy)?

Regards
Gert

we have 7 interfaces on our 220

eth0 = old network
eth1 = new network + web servers as additional addresses
eth2 = test network

eth7 = all wan public ips one as main others as additionals

spoof protection normal
strict ip handling is off
ips flood protection off

no static or policy routes.

we have 7 interfaces on our 220

eth0 = old network
eth1 = new network + web servers as additional addresses
eth2 = test network

eth7 = all wan public ips one as main others as additionals

spoof protection normal
strict ip handling is off
ips flood protection off

no static or policy routes.

Here is a shot of the command line that shows 10.10.0.1 having the incorrect mac and me statically assigning it. the macs are identicle till the very last number or letter.

Ok, and how are the interfaces of the 220 connected to switches?

Is every ethX connected to a different switch, or are two or more interfaces connected to the same switch?

Are you using VLAN?

Are you using Alias interfaces?

Do you see log lines in the packetfilter.log that show `IP-SPOOFING DROP: '?

regards
Gert

they are all on the same physical network. this was a must from the higher ups.
no vlan
no alias interfaces that I am aware of. If you mean aliased interface as in having additional addresses on the same port then yes, we have 2 ports that do this.

I do see mac spoofing being dropped. BUT its from a computer that does not use the astaro.

I just checked what ports on the astaro have what mac addresses. the computer on eth1 that is getting the incorrect mac is getting assigned eth0s mac address.

I put in a support ticket and I got a call. We talked through my setup and the only thing they thought sounded a little weird was my one interface eth1 having 2 different network on the same interface. Although they said this still shouldnt cause arp tables to be wrong, they advised putting one of the networks on its own eth. So I moved 10.10.4.1 to eth3. got all the communications back up everything working. Now time to go to that one machine on 10.10.3.0. I rebooted the machine and still it got eth0s mac address in the arp table.

another thing I noticed. On any network, lets say, 192.168.1.1 on eth2, I can ping machines on eth0 and eth1. Which is awesome. But any machine on 10.10.3.0/22 can not. Even though machines on 10.10.0.0 can. This is starting to put more wrenches in our gears.

Edit: I may know why and I am looking into it now.

Edit: Yeah no probs here. Forgot to add packet filter. Closed rule to allow full internet access so they have to use the proxy, forgot to add a rule to allow interal flow. Got that up and it works.

Ok here is what is going on. I changed the DHCP scope to not give out 10.10.3.0 ips to users. Now everyone has 10.10.2.0 ips. Why? Cause 10.10.0.0, 10.10.1.0 and 10.10.2.0 ALL get the correct arp table from the astaro. It is in fact only 10.10.3.0 addresses that get the wrong arp table mac listing for the astaro. So I will put all our printers on the 10.10.3.0 ips. They dont need internet LOL. So this will be my fix for this. But it will always be in the back of my mind asking why this is happening? Hopefully someone at astaro can let me know.

Hi Mitch, 

if I understood you correct, than you have connected multiple internal interfaces to the same internal switch. Is that correct?

If so, this can produce arp problems and spoofing protection issues.
In order to properly function in such a scenario, you need to disable the spoof protection.

If Spoofing protection is enabled, the device thinks every ethernet port is connected to a dedicated network. If a packet comes in to eth1 with a source ip from the network eth2, it is treated as a spoofing attempt and blocked. you can see this in the packetfilter logfile.

Hope that helps, 
regards
Gert

I will turn spoofing off. Unfortunatly, with it on, packets from eth1 to eth2 or whatever are not logged as spoofed and are not blocked. So this still may need some looking at.

Edit: Turning OFF spoof protection did not help the situation. I still get the incorrect arp table. I have also noticed that the other ips 10.10.1.0, 10.10.2.0 SOMETIMES get the wrong arp table. 10.10.3.0 ALWAYS gets the wrong arp table. This is insane.

Edit: Well one thing I do notice now that I turned off Spoof protection, is even though it has the incorect arp table, it still can surf. So even when the network on Eth1 that uses eth1 as a gateway has its mac address as a whole different port (eth0) it still can surf. I guess this will have to do. as long as it works consistantly. Thanks for the help. I will post here again if I find anything else concerning this.