Date: Thu, 28 May 2009 07:54:38 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: "Michael K. Smith - Adhost" <mksmith@adhost.com> Cc: freebsd-questions@freebsd.org Subject: Re: Problems with IPv6 CARP Interface in PF Message-ID: <4A1E352E.7090208@infracaninophile.co.uk> In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160605DAE7@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D5203160605DAE7@ad-exh01.adhost.lan>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkoeNTMACgkQ8Mjk52CukIwkTQCeJIU2f0dlKkPyR9rA0Urn3gv0
gloAnRcIbG5kuLxIPFxjLIhh9rMvKsJT
=20wU
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A1E352E.7090208>