I am trying to proxy 22 traffic, originated from my machine, so it will be proxied / forwarded to a remote server. This was very easy with ipfw but Yosemite has only pf ....
Did anyone found out how to rdr on local (originated from the machine) traffic on OSX Yosemite ?
this is not working !
# Custom pf Rules
#######################################
# target_ip is the ip of which I would like traffic to be proxied
target_ip = "10.0.0.2”
# porxy_ip is the proxy address
porxy_ip = "192.168.1.100”
rdr pass log on lo0 proto tcp from en0 to $target_ip port 80 -> $porxy_ip port 8080
pass out on en0 route-to lo0 inet proto tcp from en0 to $target_ip port 80 keep state
# End
any advise ?
Related
Could someone help me block all incoming traffic on my network which has port forwarding set up on the router to allow incoming requests on port 27017 to be sent to the Mac running Mongo internally except for one IP address which I can specify? I tried loading a new anchor file from /etc/pf.conf. In that file I've put the following:
rdr pass on lo0 inet proto udp from xxx.xxx.xxx.xxx to any port 27017 -> 127.0.0.1 port 27017
rdr pass on lo0 inet proto tcp from xxx.xxx.xxx.xxx to any port 27017 -> 172.0.0.1 port 27017
where xxx.xxx.xxx.xxx is the IP address I want to allow in. It does allow that address in, but I think I need to do something else to block all others. The documentation of this stuff is very dense. Any help would be appreciated.
I've confugured Dante 1.4on Ubuntu 16.04 as a socks5 proxy for Telegram.
Chats are working, but voice calls are not, failing at "Connecting".
Is there something special I need to configure in order to proxy Telegram voice traffic?
I'm using a single non priveleged (>1024) TCP/UDP port + login + password for connection.
Thanks!
UPD: Thats piece of log while i am trying to call somebody:
Apr 15 23:05:38 (1523736338.510915) danted[22977]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.36562
Apr 15 23:08:33 (1523736513.020190) danted[22989]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.49065
I can answer the call at destination device but connection is looping and getting error after 30 seconds.
Proxying UDP with socks is a bit more complex than it might seem, so let's start from the beginning.
Telegram calls use UDP with socks. Socks5 RFC1928 defines the following sequence for relaying UDP:
Client instantiates a TCP socks5 connection.
Client sends a UDP ASSOCIATE request, containing the client's source address and port, which will be used to send UDP datagrams to the socks5 Server. They might be zeros (in Telegram they are) (section 4).
Socks5 Server binds a random UDP port for relaying datagrams for this TCP socks5 connection and sends a UDP ASSOCIATE response, containing the address and port where the client should send the datagrams to be relayed (section 6).
To send a datagram, the Client must add a header to the payload, containing a destination address and port, where the server should relay that datagram (section 7).
Server will keep the UDP port bound until the TCP socks5 connection terminates.
As you can see, opening a single TCP port is not enough. For UDP to work correctly, the automatically bound UDP port must be reachable by client. NATs and Firewalls might further complicate the situation.
UDP relaying configuration with Dante
Telegram calls are Peer-to-Peer, so the udpassociate command should be allowed to 0/0:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
# udp.portrange: 40000-45000
command: udpassociate
log: error connect disconnect
}
udpreply (that's for the actual relaying, the 4'th step above) should also be allowed to everyone as well:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
command: udpreply
log: error connect disconnect
}
If your socks5 Server is behind a firewall, open a range of UDP ports (say 40000-45000) and add the udp.portrange: 40000-45000 line to the udpassociate block (see the commented out example in the first point). Then Dante would bind UDP ports in that range only.
If your socks5 Server is behind a NAT, then the returned destination address in the response to UDP ASSOCIATE request would be a local IP, rather than the external one. That local IP is unlikely to be reachable by the client, so the sent datagrams would be silently dropped.
Unfortunately, Dante uses the destination address of the TCP connection as the one where the client should send UDP datagrams to (see the comment in the source code). NAT mangles this address from an external to a local one, so the Dante's assumption that the client can reach the proxy using that destination address is broken.
A possible solution, which doesn't involve patching Dante, would be to use iptables to change the destination address from a local to the external one (assuming that it's known and doesn't change):
# 203.0.113.12 – the external IP
# 1080/tcp - Dante TCP port
# 40000:45000 – Dante UDP portrange
iptables -t nat -A PREROUTING -p tcp --dport 1080 -j DNAT --to-destination 203.0.113.12
iptables -t nat -A PREROUTING -p udp --dport 40000:45000 -j DNAT --to-destination 203.0.113.12
# If external address is not added to any network device on that
# machine, then add it to the loopback interface, so the kernel
# would know where to route the DNATed packets:
ip addr add 203.0.113.12/32 dev lo
I had the same problem. Found the solution.
You have to add udpassociate bindreply udpreply commands to conf file. here is my conf file that works with voice calls.
logoutput: syslog /var/log/danted.log
internal: ip port = 1080
external: ip
socksmethod: username
user.privileged: root
user.unprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate bindreply udpreply
log: error connect
}
Allow clients' voice traffic
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: udpreply
log: connect disconnect error
socksmethod: username
}
iptables -A INPUT -p udp -m multiport --dports 1024:65535 -j ACCEPT
You should enable calls via proxy in your telegram settings.
I am currently running a docker machine in local network that its IP & port is 192.168.99.100:8080
right now. I want to connect this machine from somewhere out of the local network and access it, so the best way I found is to NAT the sent request from my laptop computer to docker machine.
In other words, each request that has been sent to my laptop computer will be sent to the docker machine on its own IP and port!
I use pfctl to do this but when I check the port 8585 to find out which service is listening to this port, I can't find anything and it sounds like the requests do not arrive(get to) the destination!
I did as below:
1- csrutil disable
2- my pf role :
/etc/pf.anchors/mazafard:
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port 8585 -> 192.168.99.100 port 8080
3- my pf conf
/etc/pf-mazafard.conf
rdr-anchor "forwarding"
load anchor "forwarding" from "/etc/pf.anchors/mazafard"
and
sudo pfctl -vnf /etc/pf.anchors/mazafard
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port = 8585 -> 192.168.99.100 port 8080
and
sudo pfctl -evf /etc/pf.anchors/mazafard
fctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
No ALTQ support in kernel
ALTQ related functions disabled
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port = 8585 -> 192.168.99.100 port 8080
pfctl: pf already enabled
and
telnet 192.168.20.203 8585
Trying 192.168.20.203...
telnet: connect to address 192.168.20.203: Operation timed out
telnet: Unable to connect to remote host
My OSX v: 10.11.4
Docker version 1.9.1, build a34a1d5
Boot2Docker version 1.11.0-rc3, build
I am currently testing if my developing environment will run on the new upcoming Mac OS 10.11 and if I can upgrade as soon as it's released. On my test machine I am currently running the Beta Preview 3. Everything seems to be running fine.
I just can get pfctl to forward my ports. I use Vagrant and Parallels Desktop to run a Debian system for my local web server. Vagrant forwards port 8080 on the host to 80 on the guest. So 127.0.0.1:8080 works fine. But in some projects I want to have the exact same domain local as it will be in production. (without the :8080) Also I just like it more. ;-)
To do that I use pfctl to forward 80 to 8080 on the host. Here are my config files:
~/port-forwarding/pf.conf
rdr-anchor "forwarding"
load anchor "forwarding" from "/Users/nick/port-forwarding/rules.conf"
~/port-forwarding/rules.conf
rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port 443 -> 127.0.0.1 port 4433
To enable it, I run:
sudo pfctl -vnf ~/port-forwarding/pf.conf
sudo pfctl -evf ~/port-forwarding/pf.conf
This gives me this:
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
rdr-anchor "forwarding" all
Loading anchor forwarding from /Users/nick/port-forwarding/rules.conf
rdr pass on lo0 inet proto tcp from any to any port = 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port = 443 -> 127.0.0.1 port 4433
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
No ALTQ support in kernel
ALTQ related functions disabled
rdr-anchor "forwarding" all
Loading anchor forwarding from /Users/nick/port-forwarding/rules.conf
rdr pass on lo0 inet proto tcp from any to any port = 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port = 443 -> 127.0.0.1 port 4433
pf enabled
logout
Saving session...completed.
sudo pfctl -s nat says:
No ALTQ support in kernel
ALTQ related functions disabled
rdr-anchor "forwarding" all
So far it looks good, I think. But it just does not work.
127.0.0.1:80 - no connection
127.0.0.1:8080 - works
I use the same files on Yosemite and it works fine there.
Does anyone know if there's been a change on how to use pfctl or if I am doing something wrong or if there's a bug which can be reported.
Thanks a lot
Nick
This only applies to OSX 10.11 - El Capitan - Public Beta 1
x-post from: https://superuser.com/questions/938999/osx-10-11-el-capitan-beta-pf-conf-behaviour-changed/943981#943981
In the latest 10.11 beta, 127.0.0.1 is blocked. The solution? Use 127.0.0.2. To do this:
First add 127.0.0.2 to the loopback alias
sudo ifconfig lo0 alias 127.0.0.2 up
Modify your pf rule to use the the new alias.
rdr pass proto tcp from any to any port 80 -> 127.0.0.2 port 8080
From the command line, without using a file:
echo "rdr pass proto tcp from any to any port {80,8080} -> 127.0.0.2 port 8080" | pfctl -Ef - <-- Be sure to add this last tick, you're piping in STDIN)
I'm having problems with proxy/relay applications such as a BNC. I have a CentOS 5.6 VPS with 2 IP addresses which are virtual adapters (venet0:0 and venet0:1) under venet0.
In these applications I can choose which IP address to bind to (IP address of venet0:1) but when they create an outbound connection, it is done through venet0:0.
These are my current settings (found using webmin):
Interfaces
Name Type IP Address Netmask Status
lo Loopback 127.0.0.1 255.0.0.0 Up
Loopback ::1 128 Up
venet0 Unknown 127.0.0.1 255.255.255.255 Up
venet0:0 Unknown (Virtual) xxx.xxx.xxx.xxx 255.255.255.255 Up
venet0:1 Unknown (Virtual) xxx.xxx.xxx.yyy 255.255.255.255 Up
Route and Gateways
Destination Gateway Netmask Interface
169.254.0.0 None 255.255.0.0 venet0
Default Route None venet0
::1 :: 128 lo
Please can someone help me figure out how to configure the VPS?
Try to remove the default routes you do not want. The command ip route list should give you three entries. For example, on my Debian VPS, I get :
192.0.2.1 dev venet0 scope link
default via 192.0.2.1 dev venet0 src 10.15.4.62
default via 192.0.2.1 dev venet0 src 10.15.4.61
I want the VPS to use 10.15.4.61 for outgoing connections, not 10.15.4.62, so I type :
ip route del default via 192.0.2.1 dev venet0 src 10.15.4.62
Now I have a single default route, and my VPS will use the IP I want.