Re: vpn trouble
wrote: > I forgot send last time - on the other side is cisco router ... Perhaps vpnc would be easier to set up than raccoon? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
Hi.
On Tue, Jun 22, 2010 at 07:08:19PM +0200, Maciej Suszko wrote:
[]
> Set up a gif tunnel in rc.conf:
>
> cloned_interfaces="gif0"
> ifconfig_gif0="tunnel 78.x.x.x 95.x.x.x"
> ifconfig_gif0_alias0="10.20.0.1 netmask 255.255.255.255 10.10.1.90"
>
> 10.20.0.1 is your internal end of the tunnel, so use any address from
> beyond the net 10.10.1.90 is in.
Using such extra encapsulation generates different kind of IPsec
tunnels, which are sometimes used by some commercial devices (I guess
at least juniper will use a variant of that), but this is NOT the
usual way of setting up IPsec tunnels, and, afaik, this is probably
completely useless here (no extra feature provided, and I don't think
cisco devices uses such extra encapsulation).
Btw, his issue occurs with first phase1 exchange, so actually has
NOTHING to do with that part of negociation...
> in racoon.conf something like this:
>
> remote 95.x.x.x [500]
> {
> exchange_mode main,aggressive;
[]
> proposal_check obey;
This is a quite perfect example of what should NOT exist in a correct
IPsec configuration:
Once again, aggressive mode is NOT as secure as main mode, and should
be avoided as most as possible.
And proposal_check obey is really one of the worst idea people can
have when adding things to their racoon.conf, as it just disables
proposal check when we are responder
Yvan.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
Hi, I set everything like you wrote and I can send and receice packets but still I can't ping to host 10.10.1.90, and when I type #setkey -D there is no SAD entry What could it be? This is part of racoon log: Jun 23 09:43:57 czesio racoon: DEBUG: === Jun 23 09:43:57 czesio racoon: DEBUG: compute DH's private. Jun 23 09:43:57 czesio racoon: DEBUG: 5b119f45 9108a35d 61341d54 ce28f645 fac5ef8d 417013a1 455ba09f 945ab1ef 81243118 8efcdc9c f6721a38 e230ab74 8302deeb c92c06c3 6324cdf0 2bc52859 032a0bcf 516c94e3 7c99eb28 1f0cde23 9afc4515 07795202 666d124d 76d74e47 8ab70799 b48d5f67 9d228ef9 1a266f0b 194b327a 15fffe6c b87cdbd0 650ee521 Jun 23 09:43:57 czesio racoon: DEBUG: compute DH's public. Jun 23 09:43:57 czesio racoon: DEBUG: 3492c8a7 2662325a d8039260 2fc9c105 0299b9dc 3c5db323 0097677b 5d8b9f12 a9151df0 b4a9b7f5 a9121ca5 976e7a3c d7ba8024 9542fd10 2d8094e1 101c1df7 6f951335 eb12545a 51dcbea3 1bf34baa 0f673aca f8ab4dfa d93d15dc 0cd37c81 c4828967 223c4923 26b0455a 7991f75c 821d818a 1370a9dd b100a947 3f782a00 Jun 23 09:43:57 czesio racoon: DEBUG: add payload of len 128, next type 10 Jun 23 09:43:57 czesio racoon: DEBUG: add payload of len 16, next type 0 Jun 23 09:43:57 czesio racoon: DEBUG: 180 bytes from 78.x.x.x[500] to 95.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: sockname 78.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: send packet from 78.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: send packet to 95.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: 1 times of 180 bytes message will be sent to 95.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: 01505a49 433e1cff 8cb6b14b 5ec59b4e 04100200 00b4 0a84 3492c8a7 2662325a d8039260 2fc9c105 0299b9dc 3c5db323 0097677b 5d8b9f12 a9151df0 b4a9b7f5 a9121ca5 976e7a3c d7ba8024 9542fd10 2d8094e1 101c1df7 6f951335 eb12545a 51dcbea3 1bf34baa 0f673aca f8ab4dfa d93d15dc 0cd37c81 c4828967 223c4923 26b0455a 7991f75c 821d818a 1370a9dd b100a947 3f782a00 0014 c75cf3fa 12f5c5dc 0b66e5a2 4e37bdf6 Jun 23 09:43:57 czesio racoon: DEBUG: resend phase1 packet 01505a49433e1cff:8cb6b14b5ec59b4e Jun 23 09:43:57 czesio racoon: DEBUG: === Jun 23 09:43:57 czesio racoon: DEBUG: 180 bytes message received from 95.x.x.x[500] to 78.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: 01505a49 433e1cff 8cb6b14b 5ec59b4e 04100200 00b4 0a84 38b0ea0f 68a0d78e b41143b5 0b52d522 8b6a5a44 892d78fa a5ff87e5 1fdd2df8 51246c25 1743a162 0785ff3d 9e0ac5b0 39568149 8e327c35 d20459cc 44512c02 cf620450 b04a708a ae85f00d 11d58f58 c19f9b65 f8ec1cf9 160406e3 a072036c 6b2c82f2 4cc8fed5 312d4abe 75c05d7d f8f12fc9 d0cbca01 aaa62b6e 0c491a30 0014 0fdab028 1038d6ff 32782dd2 97d9208e Jun 23 09:43:57 czesio racoon: DEBUG: begin. Jun 23 09:43:57 czesio racoon: DEBUG: seen nptype=4(ke) Jun 23 09:43:57 czesio racoon: DEBUG: seen nptype=10(nonce) Jun 23 09:43:57 czesio racoon: DEBUG: succeed. Jun 23 09:43:57 czesio racoon: DEBUG: === On Tue, 22 Jun 2010 20:41:07 +0200, Maciej Suszko wrote: > "David DeSimone" wrote: >> Maciej Suszko wrote: >> > >> > > So as you write they should set: ?? >> > > 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90 >> > > (other side) >> > >> > Yes, indeed. >> > >> > > And additionaly I thing I should correct set spd policy to: >> > > >> > > spdadd 10.20.0.1 10.10.1.90 any -P out ipsec >> > > esp/tunnel/78.x.x.x-95.x.x.x/require; >> > > spdadd 10.10.1.90 10.20.0.1 any -P in ipsec >> > > esp/tunnel/95.x.x.x-78.x.x.x/require; >> > > >> > > Am I wrong? >> > >> > No, you're right :) >> > >> > You can set up the tunnel first - check whether both 10. are >> > accessible from both sides, then you "cover" communication between >> > them with IPSEC. >> >> Will this sort of GIF tunnel interoperate with Cisco and/or Checkpoint >> VPN equipment? In our tests we were able to use pure IPSEC tunnel >> encapsulation to interoperate with these sorts of devices, so we never >> found a need for GIF encapsulation. > > I'm not sure what's on the other side, AFAIK some hardware solution. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
firewalling broadcast and multicast packets
Hi all,
I just tried to block multicast and broadcast packets on a transparent
bridge with pf by filtering on one of the physical interfaces like this:
table persist {10.117.255.255/32}
netbios = "netbios-ns, netbios-dgm, netbios-ssn, mdns, ipp"
block quick on $ext_if proto ipv6
block quick on $ext_if proto udp from any port { $netbios }
block quick on $ext_if proto udp to any port { $netbios }
block quick on $ext_if inet from any to
However, the packets are still passing the bridge as can be seen with
tcpdump on the internal interface:
09:36:39.167995 IP newprintserver.fqdn-omitted.ipp >
10.117.255.255.ipp: UDP, length 94
Kernel settings are like this:
net.link.bridge.ipfw: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 1
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 1
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_onlyip: 1
I am using a recent 8.1-prerelease. Before I start putting more time in
solving this problem I just wanted to ask here if this is supposed to work
at all, or if I am doing something terribly wrong from the beginning on.
cu
Gerrit
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
On Wed, Jun 23, 2010 at 09:53:56AM +0200, r...@dzie-ciuch.pl wrote: > > Hi, Hi. > I set everything like you wrote and I can send and receice packets but > still I can't ping to host 10.10.1.90, > and when I type #setkey -D there is no SAD entry > > What could it be? > > This is part of racoon log: [] Do you have a line which says: INFO: ISAKMP-SA established Until you have such line, you still have issues with your phase 1 negociation, and we'll need almost a full debug to be able to help you (be careful: there are some private informations in such debug, like public IPs, preshared-keys, etc). Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
Ok I found that my psk.txt has got wrong permissions Now I can get SAD keys! ISAKMP-SA established 78.x.x.x[500]-95.x.x.x[500] spi:8a8881ee5182cbfb:53dab6ad5a65629d But one thing - why can't I ping 10.10.1.90? Regards Ralf On Wed, 23 Jun 2010 10:05:55 +0200, VANHULLEBUS Yvan wrote: > On Wed, Jun 23, 2010 at 09:53:56AM +0200, r...@dzie-ciuch.pl wrote: >> >> Hi, > > Hi. > > >> I set everything like you wrote and I can send and receice packets but >> still I can't ping to host 10.10.1.90, >> and when I type #setkey -D there is no SAD entry >> >> What could it be? >> >> This is part of racoon log: > [] > Do you have a line which says: > > INFO: ISAKMP-SA established > > > Until you have such line, you still have issues with your phase 1 > negociation, and we'll need almost a full debug to be able to help you > (be careful: there are some private informations in such debug, like > public IPs, preshared-keys, etc). > > > Yvan. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
On Wed, Jun 23, 2010 at 10:28:48AM +0200, r...@dzie-ciuch.pl wrote: > Ok I found that my psk.txt has got wrong permissions Yes, we'll have to set up a more explicit error message when psk file has wrong permissions. > Now I can get SAD keys! > > ISAKMP-SA established 78.x.x.x[500]-95.x.x.x[500] > spi:8a8881ee5182cbfb:53dab6ad5a65629d According to that log, you coud establish an IsakmpSA, so only the phase1 is ok Do you also have later some logs like: : INFO : IPsec-SA established: ESP/Tunnel Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
On Wed, 23 Jun 2010 10:32:29 +0200, VANHULLEBUS Yvan wrote: > On Wed, Jun 23, 2010 at 10:28:48AM +0200, r...@dzie-ciuch.pl wrote: >> Ok I found that my psk.txt has got wrong permissions > > Yes, we'll have to set up a more explicit error message when psk file > has wrong permissions. Ok. I fix it using chmod 0600 psk.txt > > >> Now I can get SAD keys! >> >> ISAKMP-SA established 78.x.x.x[500]-95.x.x.x[500] >> spi:8a8881ee5182cbfb:53dab6ad5a65629d > > According to that log, you coud establish an IsakmpSA, so only the > phase1 is ok > > Do you also have later some logs like: > : INFO : IPsec-SA established: ESP/Tunnel > Yes I got: 2010-06-23 10:18:06: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel 78.x.x.x[0]->95.x.x.x[0] spi=3926551409(0xea0a6b71) 2010-06-23 10:25:30: DEBUG: (proto_id=ESP spisize=4 spi= spi_p= encmode=Tunnel reqid=0:0) 2010-06-23 10:25:30: DEBUG: pfkey GETSPI sent: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] 2010-06-23 10:25:30: DEBUG: pfkey GETSPI succeeded: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] spi=126966409(0x7915a89) Is it good? Ralf ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
On Wed, Jun 23, 2010 at 10:37:18AM +0200, r...@dzie-ciuch.pl wrote: [...] > > Do you also have later some logs like: > > : INFO : IPsec-SA established: ESP/Tunnel > > > > Yes I got: > > 2010-06-23 10:18:06: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) > 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) > 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel > 78.x.x.x[0]->95.x.x.x[0] spi=3926551409(0xea0a6b71) > 2010-06-23 10:25:30: DEBUG: (proto_id=ESP spisize=4 spi= > spi_p= encmode=Tunnel reqid=0:0) > 2010-06-23 10:25:30: DEBUG: pfkey GETSPI sent: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] > 2010-06-23 10:25:30: DEBUG: pfkey GETSPI succeeded: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] spi=126966409(0x7915a89) > > Is it good? Looks like, but if you still can't ping, you still have an issue somewhere :-) First, check that you now have ESP packets going out from your IPsec gate when you try to ping. Then, usual issues at that step are: - something on the way blocks ESP packets. Solution may be to force NAT-T (add "nat_traversal force;" line in remote section). - IPsec peers has some filtering rules/ACLs which blocks your traffic after IPsec. - Peer does not have a default route, or somethinng like that which prevents it to reply to you. Anyways, the best tool now to see what happens is tcpdump on peer's side Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
> > Looks like, but if you still can't ping, you still have an issue > somewhere :-) > > First, check that you now have ESP packets going out from your IPsec > gate when you try to ping. > > > Then, usual issues at that step are: > > - something on the way blocks ESP packets. Solution may be to force > NAT-T (add "nat_traversal force;" line in remote section). > > - IPsec peers has some filtering rules/ACLs which blocks your traffic > after IPsec. > > - Peer does not have a default route, or somethinng like that which > prevents it to reply to you. > > Anyways, the best tool now to see what happens is tcpdump on > peer's side > When on one console i type tcpdump -i gif0 I don't receive any values! So I thing I should set route do it right? Can you tell me how to do it? netstat -rn print something like this: DestinationGatewayFlagsRefs Use Netif Expire default78.x.x.x UGS 3 49544466 bce1 10.10.1.90 10.20.0.1 UH 223813439 gif0 Is it ok? or I do something wrong? Ralf ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
On Wed, Jun 23, 2010 at 10:52:19AM +0200, r...@dzie-ciuch.pl wrote: [] > When on one console i type tcpdump -i gif0 I don't receive any values! > So I thing I should set route do it right? > > Can you tell me how to do it? > > netstat -rn print something like this: > DestinationGatewayFlagsRefs Use Netif Expire > default78.x.x.x UGS 3 49544466 bce1 > 10.10.1.90 10.20.0.1 UH 223813439 gif0 > > Is it ok? or I do something wrong? Check with your peer's configuration, but using such extra IP-IP encapsulation (via gif interfaces on FreeBSD) is NOT the usual way of setting up IPsec tunnels If your peer expects usual IPsec setups, you should just have SPD entries as specified in your very first mails. Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
Hmmm, Maybe I do some error using gateway 10.20.0.1? Maybe I have to set something in route to network 10.10.1.x go throught gif0 interface? Ralf On Wed, 23 Jun 2010 10:58:31 +0200, VANHULLEBUS Yvan wrote: > On Wed, Jun 23, 2010 at 10:52:19AM +0200, r...@dzie-ciuch.pl wrote: > [] >> When on one console i type tcpdump -i gif0 I don't receive any values! >> So I thing I should set route do it right? >> >> Can you tell me how to do it? >> >> netstat -rn print something like this: >> DestinationGatewayFlagsRefs Use Netif >> Expire >> default78.x.x.x UGS 3 49544466 bce1 >> 10.10.1.90 10.20.0.1 UH 223813439 gif0 >> >> Is it ok? or I do something wrong? > > Check with your peer's configuration, but using such extra IP-IP > encapsulation (via gif interfaces on FreeBSD) is NOT the usual way of > setting up IPsec tunnels > > > If your peer expects usual IPsec setups, you should just have SPD > entries as specified in your very first mails. > > > Yvan. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
wrote: > > Hmmm, > > Maybe I do some error using gateway 10.20.0.1? > Maybe I have to set something in route to network 10.10.1.x go > throught gif0 interface? First of all, find out what the other side configuration is. My configuration was only proposal. -- regards, Maciej Suszko. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
Thanks guys it's working. I couldn't ping 10.10.1.90 (external network) but they could ping me. I got another question: How to set another tunnel to me host like: 10.20.0.1 (my gif0) --> 78.x.x.x (my bce1) <---> 78.y.y.y <--> 10.20.1.1 I copy 2 lines (with changing ip's) so now i got 4 lines and I opy block remote and sainfo in racoon.conf. I restart racoon and now I could only connect to 95.x.x.x (like last time) but to 78.y.y.y I counldn't Is it possible to do not create interface gif1 or should I do it? Have I change someting in route table? Regards Ralf On Tue, 22 Jun 2010 20:26:36 +0200, Maciej Suszko wrote: > wrote: >> >> Hi, >> >> I try to set VPN like I wrote earlier. >> 78.x is server and this is not NAT. He dont forward anything. >> >> >> I try to configure VPN over my server and my client >> >> >> >> Sheme is like this >> >> 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 >> > >> > Are you trying to set up IPSEC tunneling of networks behind these >> > gateways, or are you only trying to secure traffic between the peers >> > themselves? >> >> I try to set tunnel behing my server 78.x and gateway 95.x translating >> packets to 10.x. I can only set 78.x side. >> >> > >> > The fact that you don't receive any reply to your IKE packets would >> > indicate something basic, like something is blocking traffic. >> >> But how to check it? Telnet to port 500 wont work. But when I set SSH >> to listen on port 500 I can login, port is not blocked > > Telnet host 500 uses proto tcp, isakmp - udp. > >> >> # setkey -DP >> >> 10.10.1.90[any] 78.x.x.x[any] any >> >> in ipsec >> >> esp/tunnel/95.x.x.x-78.x.x.x/require >> >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 >> >> 2010 lifetime: 0(s) validtime: 0(s) >> >> spid=16461 seq=1 pid=83142 >> >> refcnt=1 >> >> 78.x.x.x[any] 10.10.1.90[any] any >> >> out ipsec >> >> esp/tunnel/78.x.x.x-95.x.x.x/require >> >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 >> >> 2010 lifetime: 0(s) validtime: 0(s) >> >> spid=16460 seq=0 pid=83142 >> >> refcnt=1 >> > >> > Your IPSEC policy specifies "esp/tunnel" mode, but if you are not >> > actually encapsulating traffic originating from somewhere else, you >> > might do better to just use "transport" mode to encrypt without >> > encapsulation. >> >> Hmmm, I don't understand it? I set policy only for there IP's and >> connection for it is ESP encrypced >> >> > >> >> And tcpdump >> >> #tcpdump -i bce1 host 95.x.x.x >> >> >> >> >> >> 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> >> 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> >> 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> > >> > My first thought was that your IPSEC policy attempts to encrypt all >> > traffic between you and your peers, but the IKE traffic is also >> > traffic between you and your peers, so doesn't it lead to a policy >> > loop of some sort? Will the IPSEC layer attempt to capture and >> > encrypt the IKE packets? >> >> Can you explain how can I check it? I new on it and I don't understand >> some things. > > I've got such tunnels up and working - tunnel mode, encryption between > peers, without using any internal networks - strange, but working :) - > policy looks like that: > spdadd 195.x.x.x 213.x.x.x any -P out ipsec > esp/tunnel/195.x.x.x-213.x.x.x/require; > spdadd 213.x.x.x 195.x.x.x any -P in ipsec > esp/tunnel/213.x.x.x-195.x.x.x/require; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
But its working!! Ralf On Wed, 23 Jun 2010 13:34:52 +0200, Maciej Suszko wrote: > wrote: >> >> Hmmm, >> >> Maybe I do some error using gateway 10.20.0.1? >> Maybe I have to set something in route to network 10.10.1.x go >> throught gif0 interface? > > First of all, find out what the other side configuration is. My > configuration was only proposal. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Observations from an old timer playing with 64 bit numbers...
On Wed, 23 Jun 2010, Luigi Rizzo wrote: On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: Hi all: I have had some fun in my day job playing with exchanging 64bit numbers. Unfortunately there is no ntohll() OR htonll() which would be the logical thing (for us old farts) to use. Yes, I have found htobe64() and friends.. and that would work.. but I still cannot help but feeling we should have the ntohll() and htonll().. for consistency if nothing else. Any objections to this showing up in a head near you soon (speak soon or I will commit the patches to add these ;-D) strong objection! We should instead use names with exact sizes (16,32,64). Yes, long long should not exist, and there are few places where exact sizes should be used, but networking code is one place where they should be used. ntohs() will break semantically or actually on machines with shorts with more than 16 bits. ntohl() is already broken semantically on machines with longs with more than 32 bits (all 64-bit arches in FreeBSD). It doesn't actually handle longs on such arches. Networking code handles a few cases related to this with n_long. This is not quite as bad, but its name is nonsense -- n_long is very far from being a long -- it is unsigned 32 bits exactly, unlike long which is signed >= 32 bits. ntohll() would break similarly on machines with long longs with more or less than 64 bits. In practice this and other misuses of long long may prevent the size of long long being changed, like it prevented the size of long being changed on some systems with historical abuses of long. Bruce ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Observations from an old timer playing with 64 bit numbers...
Bruce: Comments (and questions in-line)... (you too Luigi) On Jun 23, 2010, at 6:33 AM, Bruce Evans wrote: On Wed, 23 Jun 2010, Luigi Rizzo wrote: On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: Hi all: I have had some fun in my day job playing with exchanging 64bit numbers. Unfortunately there is no ntohll() OR htonll() which would be the logical thing (for us old farts) to use. Yes, I have found htobe64() and friends.. and that would work.. but I still cannot help but feeling we should have the ntohll() and htonll().. for consistency if nothing else. Any objections to this showing up in a head near you soon (speak soon or I will commit the patches to add these ;-D) strong objection! We should instead use names with exact sizes (16,32,64). So please tell me why you object so strongly? We have the 16/32/64 bit names which are nice but are not expected so folks seem to not use them. I have received a few private comments to the effect that "Gee, we would like that, we rolled our own versions of ntohll() and if you did it we could remove our version". This tells me that although a nicer name, folks are rolling their own due to the name. Having a #define that maps ntohll -> be64toh will make it so that people can actually find the function. Name changes are a good thing for clarity but if no one will use your changed name and roll their own.. thats a bad thing. By having such a define you might encourage folks (over time) to transition off to the more clear naming versions.. Yes, long long should not exist, and there are few places where exact sizes should be used, but networking code is one place where they should be used. ntohs() will break semantically or actually on machines with shorts with more than 16 bits. So two questions here: a) What machines that we do support currently have a short larger than 16bits? b) Does anyone that use networking code really expect ntohs() to do anything different than a 16 bit byte swap? The man page is pretty clear on it i.e. uint16_t is the input and its a "network short" which if I remember right is defined to be 16 bits... At least most RFC's are pretty clear and the same is true for UNP Vol 1 ;-) ntohl() is already broken semantically on machines with longs with more than 32 bits (all 64-bit arches in FreeBSD). It doesn't actually handle longs on such arches. Networking code handles a few cases related to this with n_long. This is not quite as bad, but its name is nonsense -- n_long is very far from being a long -- it is unsigned 32 bits exactly, unlike long which is signed >= 32 bits. again same two questions only change them to say 32 bits? ntohll() would break similarly on machines with long longs with more or less than 64 bits. In practice this and other misuses of long long may prevent the size of long long being changed, like it prevented the size of long being changed on some systems with historical abuses of long. Again same first question... the second one I would ask too except the function does NOT exist (except where folks go out and roll it themselves). Basically I don't agree with your assessment since these functions are designed to operate on network code which I think defines a short = 16, a long = 32 (at least all RFC's I have read do that anyway). And it appears from feedback I have received that ntohll would be defined as a 64bit network quantity in most folks minds since that what a lot of folks have implemented... R Bruce -- Randall Stewart 803-317-4952 (cell) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Observations from an old timer playing with 64 bit numbers...
On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: ... > >>strong objection! > >>We should instead use names with exact sizes (16,32,64). > > So please tell me why you object so strongly? We have the 16/32/64 bit > names which > are nice but are not expected so folks seem to not use them. I have people's ignorance is not an excuse for not doing things right. We'd still be using BYTE, WORD and DWORD otherwise. I think there is no doubt that we should use the 16/32/64 bit names if we could start from scratch, and the only reason for not doing so is avoiding gratuitous changes to existing/stable code. The case of *to*ll does not apply, in that there is no actual legacy to adapt to. And btw there is tons of places which use the 16/32/64 bit names in the filesystem, usb and generic device drivers. In fact, many more than ntohl/htonl > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 14386397 145174 > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 2203 10269 210989 > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc 8544009 84855 > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc 7383604 72970 cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Observations from an old timer playing with 64 bit numbers...
On 6/23/10 10:12 AM, Luigi Rizzo wrote: On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: ... strong objection! We should instead use names with exact sizes (16,32,64). So please tell me why you object so strongly? We have the 16/32/64 bit names which are nice but are not expected so folks seem to not use them. I have people's ignorance is not an excuse for not doing things right. We'd still be using BYTE, WORD and DWORD otherwise. I think there is no doubt that we should use the 16/32/64 bit names if we could start from scratch, and the only reason for not doing so is avoiding gratuitous changes to existing/stable code. The case of *to*ll does not apply, in that there is no actual legacy to adapt to. And btw there is tons of places which use the 16/32/64 bit names in the filesystem, usb and generic device drivers. In fact, many more than ntohl/htonl > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 14386397 145174 > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 2203 10269 210989 > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc 8544009 84855 > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc 7383604 72970 what he said.. if you want to have ntohll in SCTP then that is your choice, but I think it should be a local define to be64toh or ntoh64 I do prefer the ntoh64 version but beXXtoh or whatever it looks like others are using is ok to me too since 'net' is a pretty wide definition and not ALL protocols are big endian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Observations from an old timer playing with 64 bit numbers...
On Jun 23, 2010, at 12:41 PM, Julian Elischer wrote: On 6/23/10 10:12 AM, Luigi Rizzo wrote: On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: ... strong objection! We should instead use names with exact sizes (16,32,64). So please tell me why you object so strongly? We have the 16/32/64 bit names which are nice but are not expected so folks seem to not use them. I have people's ignorance is not an excuse for not doing things right. We'd still be using BYTE, WORD and DWORD otherwise. I think there is no doubt that we should use the 16/32/64 bit names if we could start from scratch, and the only reason for not doing so is avoiding gratuitous changes to existing/stable code. The case of *to*ll does not apply, in that there is no actual legacy to adapt to. And btw there is tons of places which use the 16/32/64 bit names in the filesystem, usb and generic device drivers. In fact, many more than ntohl/htonl > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 14386397 145174 > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 2203 10269 210989 > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc 8544009 84855 > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc 7383604 72970 what he said.. if you want to have ntohll in SCTP then that is your choice, SCTP does not have a case for sending 64 bit things... This is my day job and other folks looking for nothll() and friends... but I think it should be a local define to be64toh or ntoh64 I do prefer the ntoh64 version but beXXtoh or whatever it looks like others are using is ok to me too since 'net' is a pretty wide definition and not ALL protocols are big endian. Well thats fine, we can let folks continue rolling there own if thats what y'all want. I really don't care actually... I already have the ifdef's in place in my day-job app code.. so its no big deal ;-) I will make this last comment.. directed at Luigi in response to: people's ignorance is not an excuse for not doing things right Then I would strongly suggest you go fix the manual page for ntohl/ ntohs and point people to the be64toh() functions... then people would NOT be ignorant. The problem is there is NO clue in the system... R -- Randall Stewart 803-317-4952 (cell) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vpn trouble
On 6/22/2010 3:55 PM, r...@dzie-ciuch.pl wrote: I managed to do an IP in IP tunnel with IPsec encryption between a FreeBSD and a cisco router running 12.1(mumble) several years ago. It is a desirable option if you want to use routing (e.g. ospf). You can't route an IPSec tunnel (actually, is this now possible with enc0 interfaces?) but you can route to the gif interfaces. Can you tell me how to use route command to use it like above? I have to admit that I no longer have access to that client's machines. However, I can describe in broad strokes. In our case the need was to provide a backup route for a dedicated T1. Occasionally the T1 would fail; so we wanted an alternate route thru the internet. The internet path had to be encrypted; but it was much slower; so we wanted the T1 to have priority. The router terminating the T1 was separate from the router providing general internet access. This was between a hospital and a service provider. A lot of this could be simplified except that the vendor HAD to provide the server, the circuit, and the router (those of you who support banks or hospitals know what I'm talking about.) There is already a static route in place for the provider via the T1 router. We first built a simple IPencap tunnel between our FreeBSD box and their cisco. The FreeBSD side used a gif and the cisco side used a tunnel interface. We confirmed that we could ping end-points. Then we added the ospf to the mix in order to detect when the T1 dropped. We weighted the ospf so that the T1 was prioritized. Once that was working we added the IPSec as transport between the endpoints of the IpinIP tunnel rather than encapsulation. That was the only time I've built an IPSec tunnel with that method. Folks with better understanding than I can perhaps explain the pros and cons. In our case, it was a simple expedient to support ospf. I have noticed since then that OS X's GUI only supports this method of IPSec tunneling; so I'm going to have to do it again to support some other customers. Some parts on the cisco side might appear thusly (I'm doing this from memory so ymmv): interface FastEthernet0.2 description VLAN 500 to Comcast router encapsulation dot1Q 500 ip address x.x.x.x 255.255.255.252 The encryption part: crypto isakmp policy 10 encr 3des hash sha1 authentication pre-share group 2 crypto isakmp key foobar-key address 0.0.0.0 0.0.0.0 crypto ipsec transform-set PROVIDER-SET esp-3des esp-sha-hmac ! crypto ipsec profile PROVIDER-PROF set transform-set PROVIDER-SET The tunnel part: interface tunnel0 description IPnIP tunnel thru comcast to PROVIDER ip address 192.168.254.3 255.255.255.252 ip ospf mtu-ignore tunnel source x.x.x.25 tunnel destination y.y.y.y tunnel mode ipsec ipv4 tunnel protection ipsec profile PROVIDER-PROF The OSPF part: router ospf 10101 log-adjacency-changes redistribute connected subnets redistribute static subnets passive interface FastEthernet0/0 passive interface FastEthernet0/0.1 passive interface FastEthernet0/0.2 network 128.1.0.0 0.0.255.255 area 0 network 192.168.8.0 0.0.3.255 area 0 network 192.168.254.0 0.0.0.3 area 0 The static route part: ip classless ip route 0.0.0.0 0.0.0.0 Serial0 ip route 192.168.8.0 255.255.252.0 10.21.1.2 ip route 192.168.20.0 255.255.255.0 10.21.1.2 ip route y.y.y.y 255.255.255.255 x.x.x.26 ! the last route is just to make sure the tunnel uses Comcast ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 and Anycast
Hi I was wondering if someon knew if FreeBSD supports the creation of anycast addresses and groups. Thanks, Paul ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv4 address: .* is not on the network
a host sees these kinds of messages Jun 7 00:20:41 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 03:38:00 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 04:32:08 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 06:55:12 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 08:52:23 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 10:02:38 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 13:19:43 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 13:32:25 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 16:32:27 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 17:46:24 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 20:59:29 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 21:54:26 r2 kernel: IPv4 address: "98.128.0.1" is not on the network yet r2# ifconfig em0: flags=8843 metric 0 mtu 9600 options=9b ether 00:1b:21:28:e2:44 inet 147.28.1.2 netmask 0xfffc broadcast 147.28.1.3 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8843 metric 0 mtu 9600 options=9b ether 00:1b:21:28:e2:45 inet 147.28.1.6 netmask 0xfffc broadcast 147.28.1.7 media: Ethernet autoselect (100baseTX ) status: active em2: flags=8802 metric 0 mtu 1500 options=19b ether 00:30:48:d4:a3:0a media: Ethernet autoselect status: no carrier em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:d4:a3:0b inet 147.28.0.5 netmask 0xff00 broadcast 147.28.0.255 inet 192.83.230.252 netmask 0xff00 broadcast 192.83.230.255 inet 198.133.206.252 netmask 0xff00 broadcast 198.133.206.255 inet 198.180.153.252 netmask 0xff00 broadcast 198.180.153.255 inet 98.128.0.3 netmask 0x broadcast 98.128.255.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 inet 147.28.7.3 netmask 0x and r2# ping -c 3 98.128.0.1 PING 98.128.0.1 (98.128.0.1): 56 data bytes 64 bytes from 98.128.0.1: icmp_seq=0 ttl=255 time=0.993 ms 64 bytes from 98.128.0.1: icmp_seq=1 ttl=255 time=144.373 ms 64 bytes from 98.128.0.1: icmp_seq=2 ttl=255 time=0.308 ms --- 98.128.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.308/48.558/144.373/67.752 ms r2# ping -c 3 98.128.0.2 PING 98.128.0.2 (98.128.0.2): 56 data bytes 64 bytes from 98.128.0.2: icmp_seq=0 ttl=64 time=1.224 ms 64 bytes from 98.128.0.2: icmp_seq=1 ttl=64 time=0.934 ms 64 bytes from 98.128.0.2: icmp_seq=2 ttl=64 time=0.776 ms --- 98.128.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.776/0.978/1.224/0.186 ms what is the issue here? randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Observations from an old timer playing with 64 bit numbers...
On 6/23/10, Randall Stewart wrote: > Then I would strongly suggest you go fix the manual page for ntohl/ > ntohs and > point people to the be64toh() functions... then people would NOT be > ignorant. > > The problem is there is NO clue in the system... Already done, at least in 7.2. But it refers you to them under the alias byteorder(9). - Bob -- -- Bob Johnson fbsdli...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
