Re: How can sshuttle be used properly with FreeBSD (and with DNS) ?
On Sat, 6 Sep 2014 02:52:22 +, John Case wrote: > I would like to use sshuttle (http://github.com/apenwarr/sshuttle) on > FreeBSD. > > I have it working for TCP connections, but it does not properly tunnel DNS > requests. The documentation for sshuttle says that ipfw forward rules will > not properly forward UDP packets, and so when it runs on FreeBSD, sshuttle > inserts divert rules instead. The project author believes that this will > work properly (inserting divert rules to tunnel UDP) but I am not having any > success. Forward doesn't update headers, likely why it's of no use to sshuttle. > BUT, I already have a divert rule (and natd running) on this system even > before I run sshuttle at all - because the system won't function as a normal > gateway unless I use divert/natd. I prefer to run a gateway without > divert/natd, but since both sides of this gateway are non-routable IPs, I > cannot do that - in order to function as a gateway with 10.x.x.x networks on > both sides, I need to run natd/divert. Or as John pointed out in your other thread, you may find it easier to use ipfw nat (in-kernel nat) instead, though sshuttle may be hard-wired to use natd. Either way, you need separate NAT instances for each task. As sshuttle needs to use divert sockets in particular, is the divert port used able to be specified? Or does it insist on using the default port natd (8668/divert)? If so, you need to use another port for your regular NAT and 8668 for sshuttle; anyway, two different ports, or you could even use natd for sshuttle and ipfw nat for regular translation. > So that means that when sshuttle inserts its own divert rules, they conflict > with the existing ones, and I am not running a second natd daemon, so I think > it all just falls apart. See natd(8) section 'MULTIPLE INSTANCES' for a well-doicumented example. And/or check ipfw(8) section 'NETWORK ADDRESS TRANSLATION (NAT)' and in the examples, 'NAT, REDIRECT AND LSNAT'. > How can this be fixed ? > > Is anyone out there using sshuttle on FreeBSD with the --dns switch ? Nope. > Here is what my ipfw.conf looks like BEFORE I run sshuttle: > > > add 1000 divert natd ip from any to any in via xl0 > add 2000 divert natd ip from any to any out via xl0 Another potential issue here; 'out via xl0' may be ambiguous, in that traffic going 'out' to anywhere, on any interface, that originally came 'in' on xl0 also matches 'out via xl0'. Unambiguous would be: add 1000 divert natd ip from any to any in recv xl0 add 2000 divert natd ip from any to any out xmit xl0 though you can save natd (or ipfw nat) some work/time if you restrict outbound nat to packets that may qualify, perhaps 'from any to any out xmit xl0 recv xl1' in the case of your regular NATting of inside net traffic, assuming xl1 to be your inside interface. 'natd' in the rules above is just the port name from /etc/services; you can use any unused port number for each (or another) instance, as per natd(8)'s multiple instances example. > and in rc.conf: > > > gateway_enable="yes" > natd_enable="yes" > natd_interface="xl0" > > > Again, this works fine - I have a functioning internet gateway and both of > the interfaces on it have non-routable IP address. > > Then I run sshuttle and it *also* works fine - but only for TCP. It does not > tunnel UDP (dns) properly like it is supposed to, and I think the reason is > that I already have diverting/natd going on and then I run sshuttle and it > inserts another two divert rules into ipfw. > > But I am not sure wha the fix would be ... Just make sure that both NAT instances use separate ports and rules. To see it in action, to confirm both regular NAT and the sshuttle UDP diversion are working correctly, run tcpdump in a couple of consoles. cheers, Ian ___ 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: How can sshuttle be used properly with FreeBSD (and with DNS) ?
On Tue, 9 Sep 2014 19:33:05, Ian Smith wrote: > add 1000 divert natd ip from any to any in recv xl0 > add 2000 divert natd ip from any to any out xmit xl0 Oops, 'ip' should nowadays be 'ip4|ipv4' for divert rules, if ip6 is configured on that interface. Last I heard, ip6 packets break divert. cheers, Ian ___ 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"
inpcb lookups in udp_send -> inpcb laddr and flowtable
Hi!
I found this whilst doing UDP RSS testing.
root@adrian-hackbox:/home/adrian/work/freebsd/head/src/sys/net #
sysctl debug.lock.prof.stats | head -2 ; sysctl debug.lock.prof.stats
| sort -nk4 | tail -5
debug.lock.prof.stats:
max wait_max total wait_total countavg wait_avg
cnt_hold cnt_lock name
4011 114900 55276 359106 0 0
0 20962 /usr/home/adrian/work/freebsd/head/src/sys/dev/ixgbe/ixgbe.c:1550
(sleep mutex:ix0:tx(6))
2111 144253 71959 454169 0 0
0 27506 /usr/home/adrian/work/freebsd/head/src/sys/dev/ixgbe/ixgbe.c:1550
(sleep mutex:ix0:tx(1))
910 3132066 8599942942422 0 0
0 35943 /usr/home/adrian/work/freebsd/head/src/sys/netinet/udp_usrreq.c:369
(sleep mutex:so_rcv)
676 1713 805307 169654 7076283 0 0
0 69741 /usr/home/adrian/work/freebsd/head/src/sys/netinet/in_pcb.c:963
(sleep mutex:rtentry)
674 4426 2111324 6415012 7076284 0 0
0 489745 /usr/home/adrian/work/freebsd/head/src/sys/net/route.c:420
(sleep mutex:rtentry)
then...
root@adrian-hackbox:/home/adrian/git/github/erikarn/freebsd-rss/rss-udp-srv
# dtrace -n 'fbt::rtalloc1_fib:entry { @[stack()] = count(); }'
dtrace: description 'fbt::rtalloc1_fib:entry ' matched 1 probe
^[[A^C
kernel`rtalloc_ign_fib+0x98
kernel`in_pcbladdr+0x7d
kernel`in_pcbconnect_setup+0x1af
kernel`udp_send+0x4af
kernel`sosend_dgram+0x30b
kernel`kern_sendit+0x20b
kernel`sendit+0x129
kernel`sys_sendto+0x4d
kernel`amd64_syscall+0x25a
kernel`0x80cd178b
1848628
It turns out that if a local address isn't bound (ie, it's INADDR_ANY)
then in_pcbladdr() will do a route table lookup to find the interface
to transmit from.
The v4/v6 laddr paths don't know about flowtable; they just do a
routing table lookup.
I'm currently experimenting with a kernel fix to use flowtable here
for IPv4 UDP sockets but I'm not sure about the IPv6 path (the source
interface/address selection is much crazier with all the various scope
bits going on.)
I'd like some help with the IPv6 source selection please!
Thanks!
-a
___
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"
[Bug 157287] [re] [panic] INVARIANTS panic (Memory modified after free)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157287 Joerg Wunsch changed: What|Removed |Added Status|In Discussion |Issue Resolved Resolution|--- |Overcome By Events --- Comment #7 from Joerg Wunsch --- The respective system has been decommisioned recently. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
Performance problem with slow link behind fast gateway
All, I'm seeing some performance problems with a slowish VPN connection behind a fast gateway, the setup looks like this: |--| |-| |client (zandbak) (DSL connection)| 'VPN tunnel' - |Gateway (vps) using NAT on 1G|-- 'Internet' |--| |-| Transfers from the gateway to the client are reasonably fast (easily within usable range for me): root@zandbak:/usr/home/rob # scp rob@gateway:test_file ./ test_file 100% 10MB 445.2KB/s 00:23 Transfers from the internet to the gateway are fast: root@vps:/usr/home/rob # fetch -4 "http://149.20.53.23/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-RELEASE-amd64-bootonly.iso"; FreeBSD-10.0-RELEASE-amd64-bootonly.iso 100% of 209 MB 10 MBps 00m20s But transfers from the client to the internet through the tunnel are showing a very degraded connection speed, the speed jumps up and down but averages at around 20kBps: root@zandbak:/usr/home/rob # fetch "http://149.20.53.23/pub/FreeBSD/ISO-IMAGES-amd64/10.0/FreeBSD-10.0-RELEASE-amd64-bootonly.iso"; FreeBSD-10.0-RELEASE-amd64-bootonly.iso 0% of 209 MB 8275 Bps 07h27m I've tried to eliminate some variables: -VPN: tinc as a L2 VPN and openVPN as a L3 VPN, results are the same -NAT: pf and ipfw, results are the same I suspect that there's a problem with the fast link receiving too much data and once the buffers are full dropping packets although I'm not sure if this is actually the problem. My question is: how can I debug this issue? Below some system information, I can supply more info if needed Thanks! Rob Evers System info: Gateway: This is a VPS on KVM root@vps:/usr/home/rob # uname -a FreeBSD vps.debank.tv 10.0-STABLE FreeBSD 10.0-STABLE #5 r268727M: Wed Jul 16 13:17:24 NZST 2014 r...@vps.debank.tv:/usr/obj/usr/src/sys/GENERIC amd64 root@vps:/usr/home/rob # ifconfig vtnet0 vtnet0: flags=8843 metric 0 mtu 1500 options=6c00ab ether 00:16:3c:55:17:b9 inet 192.227.xxx.xxx netmask 0xff00 broadcast 192.227.xxx.xxx inet6 fe80::216:3cff:fe55:17b9%vtnet0 prefixlen 64 scopeid 0x1 nd6 options=21 media: Ethernet 10Gbase-T status: active root@vps:/usr/home/rob # ifconfig tap0 tap0: flags=8843 metric 0 mtu 1500 options=8 ether 00:bd:61:01:00:00 inet6 fd7c:3e16:580b:4ccf::50 prefixlen 64 inet6 fe80::2bd:61ff:fe01:0%tap0 prefixlen 64 scopeid 0x4 inet 172.16.143.50 netmask 0xff00 broadcast 172.16.143.255 nd6 options=61 media: Ethernet autoselect status: active Opened by PID 61485 Client: This is a VM on bhyve root@zandbak:/usr/home/rob # uname -a FreeBSD zandbak 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:37:44 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@zandbak:/usr/home/rob # ifconfig vtnet0 vtnet0: flags=8943 metric 0 mtu 1500 options=80028 ether 52:54:00:13:fd:78 inet 192.168.1.129 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::5054:ff:fe13:fd78%vtnet0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet 10Gbase-T status: active root@zandbak:/usr/home/rob # ifconfig tap0 tap0: flags=8843 metric 0 mtu 1500 options=8 ether 00:bd:3d:94:05:00 inet 172.16.143.55 netmask 0xff00 broadcast 172.16.143.255 nd6 options=29 media: Ethernet autoselect status: active Opened by PID 1411 ___ 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: How can sshuttle be used properly with FreeBSD (and with DNS) ?
On Tue, 9 Sep 2014, Ian Smith wrote: On Tue, 9 Sep 2014 19:33:05, Ian Smith wrote: > add 1000 divert natd ip from any to any in recv xl0 > add 2000 divert natd ip from any to any out xmit xl0 Oops, 'ip' should nowadays be 'ip4|ipv4' for divert rules, if ip6 is configured on that interface. Last I heard, ip6 packets break divert. Thanks for your help. I will try it with two sets of nat and see how it goes... ___ 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"
Can I make this simple ipfw ruleset any more restrictive ?
I have a very simple firewall - it*blocks everything*, and the only traffic that is allowed is for internal clients to make outbound connections to tcp port 40. Also, internal clients can ping/traceroute. But that's it - no other connections in or out are allowed. I have this ruleset and it is working perfectly: ipfw add 10 allow tcp from any to any established ipfw add 20 allow icmp from any to any icmptypes 0,3,8,11 ipfw add 30 allow udp from any to any 33433-33499 in via fxp1 ipfw add 40 allow tcp from any to any 40 in via fxp1 (fxp1 is the internal interface, and so I allow the port 40 connections and the udp for traceroute only for requests that come in from the internal network) Is there anything I have screwed up here ? Any unintentional traffic that I am letting through ? Is there any way to lock this down further, and make it even more strict ? Thank yo. ___ 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: Can I make this simple ipfw ruleset any more restrictive ?
John Case wrote this message on Tue, Sep 09, 2014 at 23:37 +: > > I have a very simple firewall - it*blocks everything*, and the only > traffic that is allowed is for internal clients to make outbound > connections to tcp port 40. > > Also, internal clients can ping/traceroute. > > But that's it - no other connections in or out are allowed. I have this > ruleset and it is working perfectly: > > ipfw add 10 allow tcp from any to any established > ipfw add 20 allow icmp from any to any icmptypes 0,3,8,11 > ipfw add 30 allow udp from any to any 33433-33499 in via fxp1 > ipfw add 40 allow tcp from any to any 40 in via fxp1 > > (fxp1 is the internal interface, and so I allow the port 40 connections > and the udp for traceroute only for requests that come in from the > internal network) > > Is there anything I have screwed up here ? Any unintentional traffic that > I am letting through ? > > Is there any way to lock this down further, and make it even more strict ? You could lock down the UDP ports to a single one and remember to use -e with traceroute: -e Firewall evasion mode. Use fixed destination ports for UDP and TCP probes. The destination port does NOT increment with each packet sent. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: Can I make this simple ipfw ruleset any more restrictive ?
On 9 Sep, John Case wrote: > > I have a very simple firewall - it*blocks everything*, and the only > traffic that is allowed is for internal clients to make outbound > connections to tcp port 40. > > Also, internal clients can ping/traceroute. > > But that's it - no other connections in or out are allowed. I have this > ruleset and it is working perfectly: > > ipfw add 10 allow tcp from any to any established > ipfw add 20 allow icmp from any to any icmptypes 0,3,8,11 > ipfw add 30 allow udp from any to any 33433-33499 in via fxp1 > ipfw add 40 allow tcp from any to any 40 in via fxp1 > > (fxp1 is the internal interface, and so I allow the port 40 connections > and the udp for traceroute only for requests that come in from the > internal network) > > Is there anything I have screwed up here ? Any unintentional traffic that > I am letting through ? > > Is there any way to lock this down further, and make it even more strict ? I generally do something like that, but I also add anti-spoofing rules as well. Basically block any packets that have an inside source IP address that are received via the outside interface, and block any packets that don't have an inside IP source address that are received via the inside interface. The established keyword will let any TCP packets through that have either the ACK or RST flags set. That only blocks incoming connection attempts which have SYN without ACK. It would allow someone to scan your internal network by sending packets with ACK set and SYN not set and watching for RST packets being returned. I think you could avoid this with these two rules: ipfw add 10 check-state [...] ipfw add 40 allow tcp from any to any 40 in via fxp1 keep-state but I haven't actually done this. ___ 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"
