On Thu, Apr 8, 2010 at 11:47, James Shupe <professio...@jamesshupe.com> wrote: > My idea is to maintain a table of RTP servers, if that is possible. RTP > uses any unprivileged port (or a port above 1024) to send traffic on. Your > rule would be a rule that would allow any of that unprivileged UDP traffic > from only those hosts. It's not the perfect solution, but probably is the > most viable one. As far as I know, there is no proxy application that can > handle RTP, but you may want to investigate that further. > > pass in log inet proto udp from <rtp_servers> to $int:network port > 1024 > >> Effectively, it uses RTP. >> However, I'm not sure I don't quite understand your idea. How would >> the table be updated with which ports to redirect? Or do you mean it >> to be static with the port range currently in use? >> >> The port used seems to be random between 50000 and 60000 (something I >> have not found a reference to in anything liked to RTP). Redirecting >> them with a rule like "rdr pass on $extif proto udp from any to $extif >> port 50000:60000 -> $mypc" should work, but this does not seem like >> the proper solution. Or am I wrong? (= >> >> Isn't there a way to have this work so that, in future, MORE than one >> PC can use RTP? This isn't a MUST right now, but I would prefer to >> find some solution that would work in future. >> >> BTW James: Thank you very much, pointing out that XMPP's >> video-conference implementation uses RTP helped me google A LOT more >> info on the subject :) > <quote who="Hugo Osvaldo Barrera"> >> On Thu, Apr 8, 2010 at 10:21, James Shupe <professio...@jamesshupe.com> >> wrote: >>> Forgot to send to the list, twice! >>> >>> If it's RTP, >>> (http://en.wikipedia.org/wiki/Real-time_Transport_Protocol), >>> which some quick Googling indicates, your best bet may be to make a >>> table >>> of sending hosts with a pass ... inet proto udp ... from <table> to ? >>> port >>>>1024 rule. >>> >>> <quote who="Hugo Osvaldo Barrera"> >>>> On Thu, Apr 8, 2010 at 00:54, James Shupe <professio...@jamesshupe.com> >>>> wrote: >>>>> Use "log (all)" and tcpdump to figure out exactly what is being >>>>> blocked. >>>>> >>>>> On 4/7/10 10:40 PM, Hugo Osvaldo Barrera wrote: >>>>>> I'm using OpenBSD 4.6 at home as an access point, firewall and home >>>>>> server (with pf). >>>>>> I've recently had some issues trying to use pidgin's [XMPP] video >>>>>> support on one of my client computers, yet, if I connect it directly >>>>>> to the internet it works fine; hence the problem is the firewall >>>>>> configuration (as one of the pidgin devs pointed out it might have >>>>>> been). >>>>>> I THINK UDP packets are being dropped, but I must really say, this >>>>>> problem is a bit above my level of understanding. >>>>>> >>>>>> I need to know how to make sure UDP packets don't get dropped on the >>>>>> way to my PC, but i'm not really sure how. >>>>>> >>>>>> I think a simple "pass in proto udp" is a bit extremist (though it >>>>>> would >>>> work). >>>>>> Any better suggestions? >>>>>> >>>>>> My current pf.conf file is: >>>>>> >>>>>> ----- >>>>>> # $OpenBSD: pf.conf,v 1.44 2009/06/10 15:29:34 sobrado Exp $ >>>>>> # >>>>>> # See pf.conf(5) for syntax and examples; this sample ruleset uses >>>>>> # require-order to permit mixing of NAT/RDR and filter rules. >>>>>> # Remember to set net.inet.ip.forwarding=1 and/or >>>> net.inet6.ip6.forwarding=1 >>>>>> # in /etc/sysctl.conf if packets are to be forwarded between >>>>>> interfaces. >>>>>> >>>>>> # Skip lo >>>>>> set skip on lo >>>>>> >>>>>> ############# >>>>>> # Variables # >>>>>> ############# >>>>>> extif = "re0" >>>>>> intif = "ral0" >>>>>> chaos = "172.16.1.7" >>>>>> mamaquina = "172.16.1.12" >>>>>> >>>>>> tcp_services="{ 22, 113, 80, 443 }" >>>>>> >>>>>> icmp_types = "echoreq" >>>>>> allproto = "{ tcp, udp, ipv6, icmp, esp, ipencap }" >>>>>> privnets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 >>>>>> }" >>>>>> >>>>>> table <intnet> { 172.16.0.1/16 } >>>>>> >>>>>> # Options >>>>>> set loginterface $extif >>>>>> match in all scrub (no-df) >>>>>> >>>>>> ####### >>>>>> # NAT # >>>>>> ####### >>>>>> nat on $extif from $intif:network -> ($extif) >>>>>> # TODO Maybe move this down to service ports? Check first. >>>>>> rdr pass log on $extif proto tcp from any to any port 1022 -> $chaos >>>>>> port >>>> 22 >>>>>> >>>>>> block in >>>>>> pass out keep state >>>>>> >>>>>> antispoof quick for { lo $intif } >>>>>> >>>>>> block drop in on $extif from $privnets to any >>>>>> block drop in on $extif from any to $privnets >>>>>> >>>>>> ################# >>>>>> # SERVICE PORTS # >>>>>> ################# >>>>>> >>>>>> # Open ports for local servicesAbro puerto de servicios locales >>>>>> pass in on $extif inet proto tcp from any to ($extif) port >>>>>> $tcp_services flags S/SA keep state >>>>>> >>>>>> ### OTHER PORTS AND OPENINGS >>>>>> pass in on $extif from any to 172.16.1.7 >>>>>> pass in on $extif from any to 172.16.2.4 >>>>>> >>>>>> pass in on $extif proto {tcp, udp} from any to any port 53 >>>>>> >>>>>> # ICMP Traffic >>>>>> pass in inet proto icmp all icmp-type $icmp_types keep state >>>>>> >>>>>> # LAN - everything is allow in/out >>>>>> pass in quick on $intif >>>>>> pass out quick on $intif >>>>>> >>>>>> >>>>>> ### Block remote connections to the X Server >>>>>> block in on ! lo0 proto tcp to port 6000:6010 >>>>>> ----- >>>>>> >>>>>> Thanks for your time guys! >>>>>> >>>>>> -- >>>>>> Hugo Osvaldo Barrera >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> As I had supposed; pf is blocking the UDP packages: >>>> >>>> Apr 08 01:31:58.241781 rule 1/(match) block in on re0: >>>> <the-other-IP>.59789 > <my-ip>.50688: udp 56 >>>> Apr 08 01:31:58.363252 rule 1/(match) block in on re0: >>>> <the-other-IP>.59792 > <my-ip>.52166: udp 56 >>>> Apr 08 01:31:58.363991 rule 1/(match) block in on re0: >>>> <the-other-IP>.59793 > <my-ip>.50688: udp 56 >>>> >>>> There are several more dozen lines like this one. >>>> However, each one uses a different port, so how can I solve the >>>> problem? I don't even see a predicting which ports I'd need to open >>>> (they ARE random). >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Thank you, >>> James M. Shupe >>> GPG: 9C5C4417 >>> >>> >> >> Effectively, it uses RTP. >> However, I'm not sure I don't quite understand your idea. How would >> the table be updated with which ports to redirect? Or do you mean it >> to be static with the port range currently in use? >> >> The port used seems to be random between 50000 and 60000 (something I >> have not found a reference to in anything liked to RTP). Redirecting >> them with a rule like "rdr pass on $extif proto udp from any to $extif >> port 50000:60000 -> $mypc" should work, but this does not seem like >> the proper solution. Or am I wrong? (= >> >> Isn't there a way to have this work so that, in future, MORE than one >> PC can use RTP? This isn't a MUST right now, but I would prefer to >> find some solution that would work in future. >> >> BTW James: Thank you very much, pointing out that XMPP's >> video-conference implementation uses RTP helped me google A LOT more >> info on the subject :) >> >> >> >> > > > -- > Thank you, > James M. Shupe > GPG: 9C5C4417 > >
Nope, no luck... but I can't seem to figure out what the problem is. I've been trying all weeked, redirecting the ports, even ALL ports, to my PC, and logging everything. The best I've achived is: Apr 11 23:25:18.537585 rule 1/(match) pass in on re0: remote-ip.55972 > local-ip.52104: udp 88 (DF) Apr 11 23:25:18.537623 rule 1/(match) pass out on re0: local-ip > remote-ip: icmp: local-ip udp port 52104 unreachable Apr 11 23:25:18.561570 rule 1/(match) pass in on re0: remote-ip.39120 > local-ip.55280: udp 88 (DF) Apr 11 23:25:18.561594 rule 1/(match) pass out on re0: local-ip > remote-ip: icmp: local-ip udp port 55280 unreachable It seems that packets incoming from the internet come in ok, but packets outgoing appear to be rejected at destination. Is this correct? :/ I DON'T understand why using the OpenBSD firewall in the middle, I get this error, however, if I connect my PC directly to the internet (phisically removing the internet cable from the OpenBSD server and pluging it into my PC), it works fine. I've done SEVERAL tests, with no better results than these. As a temporary measure, I'm using a TURN server to relay my connection, however, I very much dislike this idea, considering **I** am the one in charge of properly configuring my gateway.
