catalin visinescu <[EMAIL PROTECTED]> wrote:
>>Hello,
>>
>>Intro:
>>I am using isakmpd+sasyncd+carp+pf+pfsync to have a redundant
>>firewall setup (OpenBSD 4.0). I have two firewall that carp-advertise at
the
>>same rate, and not preempt each other. This works fine. isakmpd is using
>>x509 certificates to establish SAs. This is working fine. sasyncd is
>>running on both and they share the SAs properly. pfsync has been
>>configured and it is working well.
>>
>>I have the following setup (netmask is /24 everywhere):
>>
>>Redundant end
>>FW1: Ext IP: 172.16.140.2 (static) Int IP: 172.16.36.2 (static)
>>FW2: Ext IP: 172.16.140.3 (static) Int IP: 172.16.36.3 (static)
>>FW1 and FW2 shared IP addresses (carp)
>>Ext IP: 172.16.140.1
>>Int IP: 172.16.36.1
>>
>>
>>Non-redundant end:
>>Ext IP: 172.16.142.1 (static)
>>Int IP: 172.16.40.1 (static)
>>
>>
>>Problem:
>>Assume the gateway that has static IP 172.16.36.2 is the master. I
>>ping from 172.16.40.1 to 172.16.36.1 (or 172.16.36.2) and the ping goes
>>through. The moment I ping the backup (ping -c 1 -I 172.16.40.1 172.16.36.3)
>>>>I get a reply, but I can no longer ping 172.16.36.2. Now I can only ping
>>the second gateway (goes in through the master, goes out through the
>>backup). Everything goes back to normal (I can ping 172.16.36.2) the >>moment
>>a new quick mode is finished and new SAs are established.
>>
>>Question:
>>Why is this happening? I would like to have remote access to the
>>backup gateway, for instance for live status polling (that's why I have the
>>static IP addresses), or sync NTP time on firewalls (time source over
>>secure tunnel). I don't mind if when I ping 172.16.36.3 the packet goes
>>in through the first gateway and goes out through the second (because
>>the flows are already set). I just don't want to block the communication
>>on messages to the backup gateway.
>>
>>
>>Can anyone help with this issue?
>>./catalin
>>
Hello,
I understand now why this happens... it is a problem with the packet filter not
updating the sequence numbers correctly.
When I ping the master firewall the sequence numbers used are the same for
both directions (SPIs)... (100,100) let's say.
When I ping the backup, the request goes through master and goes out through
the backup with sequence numbers (101, and 16485).
That is normal behaviour and is documented here
http://members.iinet.net.au/~nathanael/OpenBSD/sasyncd.html (section 1.5)
Let's say 172.16.36.2 is the master...
From the non-redundant end:
ping -c 1 172.16.40.1 172.16.36.2 OK seq:100 request, 100 reply
(sniffing on pfsync0 of the master firewall shows an updated seq # being sent
to the backup firewall for that SPI)
ping -c 1 172.16.40.1 172.16.36.3 OK seq:101 request, 101+16384=16485 reply
(sniffing on pfsync0 of the master firewall shows an update being sent to the
backup firewall)
(sniffing on pfsync0 of the backup firewall shows an update being sent to the
master firewall)
NOTE THAT THE MASTER USES THE UPDATE FROM BACKUP.
ping -c 1 172.16.40.1 172.16.36.2 OK seq:102 request, 16485+16384= 32869 reply
(sniffing on pfsync0 of the master firewall shows an update being sent to the
backup firewall)
ping -c 1 172.16.40.1 172.16.36.2 OK seq:103 request, 16485+16384= 32870 reply
(sniffing on pfsync0 of the master firewall shows an update being sent to the
backup firewall)
This part is clear... whenever a firewall has something to send, it is adding
1 to the previous sequence # if it sent the last
message and it adds 16384 if the sequence # it has was received using pfsync
from the other firewall. That I see in if_pfsync.c
However if I change the test just a little bit...
ping -i .1 172.16.40.1 172.16.36.2 OK seq:100 request, 100 reply, and so on
(sniffing on pfsync0 of the master firewall shows an update being sent to the
backup firewall)
and at some point:
ping -c 1 172.16.40.1 172.16.36.3 OK seq:101 request, 101+16384=16485 reply
(sniffing on pfsync0 of the backup firewall shows an update being sent to the
master firewall)
The communication to 172.16.36.2 stops as the master does not get the update of
the seq # for that SPI. The update is sent though (sniffing pfsync). As soon as
a new SA is established
everything (obviously) goes back to normal. THE MASTER DOES NOT USE THE UPDATE
FROM THE BACKUP.
This is quite bizarre that sending this one packet stops the traffic to
172.16.36.2. I would expect some packets to be lost until the master receives
the update from the backup though (up to a second).
I will take a look at if_pfsync.c and check why this happens.
Hope this helps.
./catalin
---------------------------------
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot
with the All-new Yahoo! Mail
