2 physical eth-devices on same Ethernet allowed?

Many OS's, including Linux, can get confused when 2 NICs are on the same physical network.

It's probably not a good idea.

You should be able to do traffic analysis on the firewall using the TUN interface, or on a sniffer by filtering for IPSEC.

Barry

Many OS's, including Linux, can get confused when 2 NICs are on the same subnet.

They are on the same Ethernet.
They are not on the same subnet:

eth0: unencrypted Internet traffic is on subnet x.y.8.100/25
eth1: all IPsec Internet traffic for site-to-site VPNs is on subnet x.y.14.200/28

However, as Astaro seems to be affected by that strange limitation of Linux, I will remove eth1 and switch the IPsec gateway address to eth0.

Isenberg, the issue is the same physical network (Ethernet).

I want to have dedicated traffic analysis for all IPsec traffic

If you could expand on that description, perhaps we could make more suggestions.

a simple and safe reject rule for all RFC1918 private networks coming in or sending out wrongly via eth0.

In defining the IPsec VPN you define the subnets that are routed through the tunnel, and in defining the packet filter rules, you select the traffic allowed out.  It's not possible for any other traffic to pass, so I'm confused by this comment.

eth0: unencrypted Internet traffic is on subnet x.y.8.100/25
eth1: all IPsec Internet traffic for site-to-site VPNs is on subnet x.y.14.200/28

I'm confused also that you seem to have two such different subnets that might not have the same gateway ot the same ISP.  If that's the case, then we should be talking about Uplink Balancing and Multipath rules.

I will remove eth1 and switch the IPsec gateway address to eth0.

If you want that traffic to come from another IP, put the additional IP on eth0 (let's call it "IPsec Traffic"), then create a NAT rule:

External (Address) -> IPsec -> Any : SNAT from External [IPsec Traffic]  (Address) {leave 'Source Service' empty!}

Cheers - Bob

Bob, thanks for the correction.

Barry

Both external networks do exists, but one is routed via the others defaults gateway, so no multipath or loadbalancing possible.

With the 2nd NIC for ipsec0 I tried to recreate the following simplified rules I would use on a bare iptable firewall:

iptables -A INPUT -i eth0 -d myexternalnet/25 -j ACCEPT
iptables -A INPUT -i eth0 -j REJECT
iptables -A INPUT -i ipsec0 -d mylocalnet/24 -j ACCEPT
iptables -A INPUT -i ipsec0 -j REJECT

As the interface attribute can only be given to a NIC on astaro and not the ipsec virtual NIC, I used the 2nd hardware NIC not being aware of possible problems with that.

Your suggestion with the SNAT should indeed solve the situation, even without any change on the remote IPsec clients. I'll move the ip addr of eth1 to an alias on eth0, switch off eth1 and set eth0 as IPsec gateway with the SNAT rule on the former eth1 addr. 

Bob, Barry, thanks for your suggestions and information!

Isenberg, Thanks for the explanation.  I don't know mucxh about iptables, but I learned from your example and I see now why you asked the question in the way you did.

Cheers - Bob
PS Barry, I didn't think I said anything to correct you; I thought I just expanded on what you were saying after isenberg responded to you in Post #3.  But, hey! - Thanks for the recognition!

I said subnet when I should have said switch or physical network.

Barry

Now I removed device settings for eth1 (the former ipsec-gateway) and moved its ip address to the standard Internet interface eth0. After adding the SNAT rule, now all IPsec connections are available like before without changing anything and tcpdump does not show any unencrypted packets any more on eth0. Thanks.

Holger