Two Networks on one System

[Damien Fleuriot]

On 6/21/11 2:32 AM, Jerome Herman wrote:
> On 21/06/2011 00:13, Jon Radel wrote:

> So depending on the client route, packets from a given IP address can
> land on either interface. Actually two clients nated behind the same
> public address might end up on both interfaces at the same time.
> Even though your solution should work 99% of the time , it can lead to
> pretty strange behavior. I am not completely sure of how reply-to works,
> notably with keep state (and of course OpenBSD manuals on PF are down
> right now, at least from here). I remember attempting similar setups and
> having quite a lot of trouble with ICMP (especially RST for that matter).
> 

This does not depend on the route the client takes, but rather on the IP
the client tries to reach, wouldn't you agree ?


Our PF boxes have 2 public IP addresses in 2 totally different networks,
as well as public shared CARP IPs.


Example:

# PASS quick ICMP from trust IPs
pass in quick on $ifvlan13 reply-to ($ifvlan13 $neo_vrrp_195) inet proto
icmp from <allowed_ssh> to <myself_wan_195> icmp-type echoreq label
"PASS in icmp_195"
pass in quick on $ifvlan13 reply-to ($ifvlan13 $neo_vrrp_46) inet proto
icmp from <allowed_ssh> to <myself_wan_46> icmp-type echoreq label "PASS
in icmp_46"


If you reach the box on it's 195.158.x.x IP (physical or carp), it'll
reply through its router in the 195.158.x.x network

If you reach the box on it's 46.182.x.x IP (physical or carp), it'll
reply through its router in the 46.182.x.x network

This is a production payment system so we'd know if there was trouble ;)


> I guess that in order to cover all solutions there would be need to know
> what is exactly happening. The most important thing would be to know if
> both IP addresses on the server are public, or if there are private with
> DMZ/Port routing/NAT etc.

Doesn't change much.


> If there is only a master DNS on the server, then I guess the worst
> thing that could happen would be strange timeouts and connection reset.
> But I there are data to be updated from the outside (DB, slave DNS,
> logs, mails etc.) things could turn out pretty badly.
> 
> Actually I think the rules should be following not only the IP, but also
> the flags and the ports. Keep-state should take care of this once the
> connection is properly initiated, but during handshake I do not see how
> to guarantee proper resolution.
> 

AFAIK during the TCP three-way handshake the initiator presents itself
with a source IP and port and a destination IP and port, the source
tracking does exactly what you're describing.