Problems with IPv6 CARP Interface in PF

Matthew Seaman m.seaman at infracaninophile.co.uk
Thu May 28 06:55:06 UTC 2009


Michael K. Smith - Adhost wrote:
> Hello:
> 
> I'm having reachability problems with a CARP interface set up on two 7.1
> boxes with an uplink to Cisco routers.  However, the inside CARP address
> on the same set of PF boxes are reachable with no trouble.  Here's the
> config.
> 
> Cisco 		Cisco
>        HSRP Gateway
>             |
>        CARP Interface 1
> PF Box               PF Box
>        CARP Interface 2
>             |
>           Server
> 
> When I try to ping CARP Interface 1 above from the Internet, I get no
> response.  When I ping the CARP Interface 2, which has a route set from
> the Cisco's to CARP Interface 1, it works.  Here's what I see in my
> logs.
> 
> 00:38:45.763975 IP6 fe80::203:6cff:fef9:2c00 > ff02::1:ff00:7: ICMP6,
> neighbor solicitation, who has 2001:4970:cccc::7, length 32
> 
> ... with no response.
> 
> Here is the ifconfig from one box.
> 
> carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
>         inet6 2001:4970:cccc::6 prefixlen 64
>         inet6 2001:4970:cccc::7 prefixlen 64
>         carp: MASTER vhid 1 advbase 1 advskew 100
> carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
>         inet6 2001:4970:cccc:aaaa::1 prefixlen 64
>         carp: MASTER vhid 2 advbase 1 advskew 100
> 
> and the other shows appropriately as "BACKUP".  There is no change if I
> run with just one PF box.
> 
> Any help would be greatly appreciated.

* Do you have PF rulesets written to take account of the CARP interfaces
  and IPs correctly?  You can say things like:

    pass in on carp0 proto icmp6 from any to { carp0 carp1 } keep state 

  You may not need carp specific rules if the carp IP is from the same
  network as the IPs on the front interfaces of those PF boxes, and your
  rules are written to filter traffic crossing those interfaces by network
  (say) rather than by specific IP numbers.  

  A good debugging trick is to make sure that all pf rules that block 
  packets have a log clause, and then tcpdump pflog0 while doing your
  connectivity tests.  Immediately tells you if its PF blocking things
  rather than some other problem.

* I'm sure this is far too obvious, but in case you've tripped over this
  one accidentally:

    pass ... proto inet ....

  only allows IPv4.  Either drop the proto clause altogether, or add explicit
  'proto inet6' rules.

* Have you tried tcpdump on the various physical and carp interfaces on those
  machines while trying to ping?  Probably the most interesting data to be gleaned
  from that is if there are ping responses being sent, and what IP they originate
  from.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090528/9d360efa/signature.pgp


More information about the freebsd-questions mailing list