On Fri, Aug 16, 2002 at 01:28:38AM +0000, Vadim Pushkin wrote:
> >From: "Crist J. Clark" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >
> >[snip]
> >
> >> >> # 192.168.1.0 is my Unnatted/internal network.
> >> >> #
> >> >> pass in proto esp from vpn.XXX.net/32 to 192.168.1.0/24
> >> >> pass out proto esp from 192.168.1.0/24 to vpn.XXX.net/32
> >> >
> >> >Find out if you are using ESP or 10000/udp.
> >>
> >> I am seeing alot of isakmp traffic getting blocked. I _believe_
> >> that it is ESP.
> >
> >You seem to be very confused. ISAKMP rides over 500/udp. UDP is an IP
> >protocol (protocol 17 to be exact). ESP, Encapsulated Security
> >Payload, is a completely separate IP protocol (protocol 50).
>
> Thank you. What I am seeing is the following from tcpdump, but what
> puzzles me is the fact that I sometimes see VPN.XXX.NET.IP, and some
> times I see VPN.XXX.NET-ROUTER.IP, which are not even the same subnet.
> See belows output sample.
>
> 21:05:38.838016 204.177.198.17.isakmp > VPN.XXX.NET.IP.isakmp: isakmp v1.0
> exchange INFO encrypted
> cookie: 77ebe015bdc5ecce->2b4ea8a31d8bf87f msgid: fe44266a len: 84
> 21:05:38.855278 VPN.XXX.NET.IP.isakmp > 204.177.198.17.isakmp: isakmp v1.0
> exchange INFO encrypted
> cookie: 77ebe015bdc5ecce->2b4ea8a31d8bf87f msgid: e58d1012 len: 84
> 21:05:49.853889 204.177.198.17.isakmp > VPN.XXX.NET.IP.isakmp: isakmp v1.0
> exchange INFO encrypted
> cookie: 77ebe015bdc5ecce->2b4ea8a31d8bf87f msgid: afa02b26 len: 76
Looks reasonable.
> 21:05:49.854443 204.177.198.17.10346 > VPN.XXX.NET.IP.10000: udp 1
> 21:05:49.871418 VPN.XXX.NET-ROUTER.IP > 204.177.198.17: icmp: host
> VPN.XXX.NET-ROUTER.IP unreachable - admin prohibited filter
OK, it looks like a firewall at the remote site, VPN.XXX.NET-ROUTER.IP,
is blocking the VPN packets (10000/udp). Run tcpdump with '-vvv' to
print all the detail it can, especially to print the details about the
header of the packet that caused the ICMP error message.
But it seems pretty clear the remote site is blocking the VPN. They
will need to modify the policy on VPN.XXX.NET-ROUTER.IP to allow
10000/udp from your network to go to VPN.XXX.NET.IP.
> >> pass out quick on sis0 proto tcp from any to any flags S keep state
> >> pass out quick on sis0 proto udp from any to any keep state
> >> pass out quick on sis0 proto icmp from any to any keep state
> >> pass out quick on sis0 proto esp from any to any keep state
> >> #
> >> pass in quick on sis1 proto tcp from any to 192.168.1.254 port = 22
> >flags
> >> S/SA
> >> pass out quick on sis1 proto tcp from 192.168.1.254 port = 22 to any
> >flags
> >> S/SA
> >
> >A TCP SYN with a _source_ port of 22?
>
> ssh?
ssh _listens_ on port 22. The client will send a SYN _to_ 22. Only the
first of those two rules makes any sense.
> >> pass out quick on sis1 proto icmp all icmp-type 0
> >> pass out quick on sis1 proto icmp all icmp-type 3
> >> pass out quick on sis1 proto icmp all icmp-type 11
> >> #
> >> pass out quick on sis1 proto udp from 192.168.1.254 port = 53 to any
> >> pass out quick on sis1 proto udp from 192.168.1.0 port = 53 to any
> >
> >Huh?
>
> Allows my internal machines to resolve against an external DNS server, no?
It allows the host at 192.168.1.254 to do UDP queries. It allows the
host at 192.168.1.0 to do UDP queries. But I would guess you do not
actually have a host at 192.168.1.0. The IP addresses 192.168.1.1
through 192.168.1.253 cannot do UDP queries. Is that the intended
policy?
> >> pass in quick on sis0 proto tcp from any to any port = 25 flags S/SA
> >keep
> >> state
> >> pass in quick on sis0 proto tcp from any to any port = 29204 flags S/SA
> >keep state
> >> pass in quick on sis0 proto tcp from any to any port = 22 flags S/SA
> >keep state
> >> block in log quick on sis0 proto tcp all flags S/SA
> >> block out log quick on sis0 proto tcp all flags S/SA
> >> block out on sis1 proto tcp all flags S/SA
> >> block out on sis1 proto udp all
> >> block out on sis1 proto icmp all
> >
> >You still seem to be missing some rules on sis1. I don't see how any
> >of this works. I don't see how you can ever get a connection from your
> >internal network out to the Internet.
>
> But I tell you it does :-)
Well, I still don't see how anything gets out.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/ | [EMAIL PROTECTED]
