i386/110393: parameter syncpeer only works if ip address is backwards

[Alejandro Gramajo]

>Number:         110393
>Category:       i386
>Synopsis:       parameter syncpeer only works if ip address is backwards
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 16 15:00:15 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Alejandro Gramajo
>Release:        6.1-RELEASE
>Organization:
BAICOM Networks
>Environment:
FreeBSD fleni-fw2.fleni 6.1-RELEASE FreeBSD 6.1-RELEASE #2: Fri Sep 22 14:47:51 ART 2006     root at fleni-fw.16.1.27:/usr/src/sys/i386/compile/MYKERNEL  i386

>Description:
2 firewalls with 3 ethernet interfaces.
  - rl0 (wan / internet)
  - re0 (dmz) [ fw1: 172.21.0.101  fw2: 172.21.0.102 ]
  - re1 (lan)

2 virtual interfaces
  - carp0 (dmz gateway)
  - carp1 (lan gateway)

Pfsync
  - syncdev re0
  - for fw1 set syncpeer 172.21.0.102
  - for fw2 set syncpeer 172.21.0.101

When I set the syncpeer parameter of pfsync0, it is not work.
Because it's try to connect to the internet, to the backwards ip address

FW2 (the master)
# ifconfig pfsync0 syncdev re0 syncpeer 172.21.0.101
# ifconfig pfsync0
pfsync0: flags=0<> mtu 1348
        pfsync: syncdev: re0 syncpeer: 172.21.0.101 maxupd: 128

You can see the tcpdump's output (rl0 is the ethernet for wan connections)

# tcpdump -n -c 3 -i rl0 proto pfsync
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes
11:32:52.187251 IP 200.41.236.244 > 101.0.21.172:  pfsync 532
11:32:52.232685 IP 200.41.236.244 > 101.0.21.172:  pfsync 180
11:32:52.232696 IP 200.41.236.244 > 101.0.21.172:  pfsync 452
3 packets captured
198 packets received by filter
0 packets dropped by kernel

The FW1 has exactly the same behaviour. 

And another problem, that I observe here, is the psyncdev parameter. 
What parameter is more important to decide 
 
I only a found one reference to this apparently bug. And with no answer.
http://lists.freebsd.org/pipermail/freebsd-pf/2006-April/002084.html

>How-To-Repeat:
FW2:
# ifconfig pfsync0 syncdev re0 syncpeer 172.21.0.101
# ifconfig pfsync0
pfsync0: flags=0<> mtu 1348
        pfsync: syncdev: re0 syncpeer: 172.21.0.101 maxupd: 128

# tcpdump -n -c 3 -i rl0 proto pfsync
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes
11:32:52.187251 IP 200.41.236.244 > 101.0.21.172:  pfsync 532
11:32:52.232685 IP 200.41.236.244 > 101.0.21.172:  pfsync 180
11:32:52.232696 IP 200.41.236.244 > 101.0.21.172:  pfsync 452
3 packets captured
198 packets received by filter
0 packets dropped by kernel

>Fix:
Put the backwards ip address in syncpeer. ( 172.21.0.101 -> 101.0.21.172 )

FW2:
# ifconfig pfsync0 syncpeer 101.0.21.172 syncdev re0
# tcpdump -n -c 3 -i re0 proto pfsync
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes
11:39:12.569303 IP 172.21.0.102 > 172.21.0.101:  pfsync 532
11:39:12.629316 IP 172.21.0.102 > 172.21.0.101:  pfsync 532
11:39:12.650105 IP 172.21.0.102 > 172.21.0.101:  pfsync 532
3 packets captured
122 packets received by filter
0 packets dropped by kernel

You can see now that packets are send via re0 interface correctly.
And everything seems to work fine.

>Release-Note:
>Audit-Trail:
>Unformatted: