Jump to content
Not connected, Your IP: 3.144.93.14
Sign in to follow this  
kittyberry

Do NOT forward on your router the same ports...?

Recommended Posts

So, I will look like a complete noob while asking this question, but better safe than sorry. What exactly is meant by the note on the bottom of the p2p FAQ (IMPORTANT: do NOT forward on your router the same ports you use on your Bittorrent or eMule client (or any other listening service) while connected to the VPN. Doing so exposes your system to correlation attacks and potentially causes uncencrypted packets to be sent outside the tunnel from your client.)? I'm mostly using the vpn to keep my torrent downloads anonymous (my ISP has already warned me about it), so I think it's really important for me to understand everything that has to do with using airvpn and BitTorrent. So I've forwarded one port and have set it up on BitTorrent via the instructions provided. I've done nothing else with the forwarding of ports/setting them up. Am I in the clear? Thanks. c:

Share this post


Link to post

So, I will look like a complete noob while asking this question, but better safe than sorry. What exactly is meant by the note on the bottom of the p2p FAQ (IMPORTANT: do NOT forward on your router the same ports you use on your Bittorrent or eMule client (or any other listening service) while connected to the VPN. Doing so exposes your system to correlation attacks and potentially causes uncencrypted packets to be sent outside the tunnel from your client.)? I'm mostly using the vpn to keep my torrent downloads anonymous (my ISP has already warned me about it), so I think it's really important for me to understand everything that has to do with using airvpn and BitTorrent. So I've forwarded one port and have set it up on BitTorrent via the instructions provided. I've done nothing else with the forwarding of ports/setting them up. Am I in the clear? Thanks. c:

Hello!

Yes, you're fine, just do not forward ports on your router.

If you forward both remotely and on your router the same ports, an adversary with the ability to monitor/wiretap your line can send packets to the same port both on the exit-IP of the VPN server you're connected to and to your real IP address. If the service you're running responds also the the packets arriving to your real IP address outside the tunnel, the adversary have established a correlation between you and the VPN usage on that port.

Kind regards

Share this post


Link to post

More on this topic .. on the 'ports' page it is noted "configure your firewall to block connections outside the tunnel to these ports". My connection is as a OpenVPN client on a DD_WRT router and the standard set of iptables commands is in place (iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT iptables -I INPUT -i tun0 -j REJECT

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE) ... is this sufficient or must something specific be done with the forwarded port?TIA!

Share this post


Link to post

More on this topic .. on the 'ports' page it is noted "configure your firewall to block connections outside the tunnel to these ports". My connection is as a OpenVPN client on a DD_WRT router and the standard set of iptables commands is in place (iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT iptables -I INPUT -i tun0 -j REJECT

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE) ... is this sufficient or must something specific be done with the forwarded port?TIA!

Hello!

Can you please send us the complete iptables tables/chains? The rules you mention do not appear to prevent leaks from your br0 in case of VPN disconnection.

Kind regards

Share this post


Link to post

Not sure if this is what is wanted?

root@DD-WRT:~# iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

logaccept 0 -- anywhere anywhere

REJECT 0 -- anywhere anywhere reject-with icmp-po

rt-unreachable

logaccept 0 -- anywhere anywhere state RELATED,ESTAB

LISHED

logdrop udp -- anywhere anywhere udp dpt:route

logdrop udp -- anywhere anywhere udp dpt:route

ACCEPT udp -- anywhere anywhere udp dpt:route

logdrop icmp -- anywhere anywhere

logdrop igmp -- anywhere anywhere

ACCEPT 0 -- anywhere anywhere state NEW

logaccept 0 -- anywhere anywhere state NEW

logdrop 0 -- anywhere anywhere

Chain FORWARD (policy ACCEPT)

target prot opt source destination

ACCEPT 0 -- anywhere anywhere

ACCEPT 0 -- anywhere anywhere

logaccept gre -- 192.168.1.0/24 anywhere

logaccept tcp -- 192.168.1.0/24 anywhere tcp dpt:1723

logaccept 0 -- anywhere anywhere

TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/S

YN TCPMSS clamp to PMTU

lan2wan 0 -- anywhere anywhere

logaccept 0 -- anywhere anywhere state RELATED,ESTAB

LISHED

TRIGGER 0 -- anywhere anywhere TRIGGER type:in mat

ch:0 relate:0

trigger_out 0 -- anywhere anywhere

logaccept 0 -- anywhere anywhere state NEW

logdrop 0 -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Chain advgrp_1 (0 references)

target prot opt source destination

Chain advgrp_10 (0 references)

target prot opt source destination

Chain advgrp_2 (0 references)

target prot opt source destination

Chain advgrp_3 (0 references)

target prot opt source destination

Chain advgrp_4 (0 references)

target prot opt source destination

Chain advgrp_5 (0 references)

target prot opt source destination

Chain advgrp_6 (0 references)

target prot opt source destination

Chain advgrp_7 (0 references)

target prot opt source destination

Chain advgrp_8 (0 references)

target prot opt source destination

Chain advgrp_9 (0 references)

target prot opt source destination

Chain grp_1 (0 references)

target prot opt source destination

Chain grp_10 (0 references)

target prot opt source destination

Chain grp_2 (0 references)

target prot opt source destination

Chain grp_3 (0 references)

target prot opt source destination

Chain grp_4 (0 references)

target prot opt source destination

Chain grp_5 (0 references)

target prot opt source destination

Chain grp_6 (0 references)

target prot opt source destination

Chain grp_7 (0 references)

target prot opt source destination

Chain grp_8 (0 references)

target prot opt source destination

Chain grp_9 (0 references)

target prot opt source destination

Chain lan2wan (1 references)

target prot opt source destination

Chain logaccept (8 references)

target prot opt source destination

LOG 0 -- anywhere anywhere state NEW LOG level

warning tcp-sequence tcp-options ip-options prefix `ACCEPT '

ACCEPT 0 -- anywhere anywhere

Chain logbrute (0 references)

target prot opt source destination

0 -- anywhere anywhere recent: SET name: B

RUTEFORCE side: source

RETURN 0 -- anywhere anywhere !recent: UPDATE sec

onds: 60 hit_count: 4 name: BRUTEFORCE side: source

RETURN 0 -- anywhere anywhere limit: avg 1/min bu

rst 1

logdrop 0 -- anywhere anywhere

Chain logdrop (7 references)

target prot opt source destination

DROP 0 -- anywhere anywhere

Chain logreject (0 references)

target prot opt source destination

REJECT tcp -- anywhere anywhere reject-with tcp-res

et

Chain trigger_out (1 references)

target prot opt source destination

Share this post


Link to post

So I currently have the following rules:

iptables -I FORWARD -i br0 -o tun0 -j ACCEPT

iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

iptables -I INPUT -i tun0 -j REJECT

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

The quoted thread suggests the following:

iptables -I FORWARD -i wl0 -o tun+ -j ACCEPT

iptables -I FORWARD -i tun+ -o wl0 -j ACCEPT # make sure that eth+ and tun+ can "communicate"

iptables -I INPUT -i tun+ -j REJECT

iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE # in the POSTROUTING chain of the NAT table, map the tun+ interface outgoing packet IP address, cease examining rules and let the header be modified, so that we don't have to worry about ports or any other issue - please check this rule with care if you have already a NAT table in your chain

iptables -I OUTPUT -o eth+ ! --dst 50.115.127.44 -j DROP # if destination for outgoing packet on eth+ is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects

# the above line can be duplicated for as many Air servers as you wish to connect to, just insert the appropriate Air server entry-IP8888888888888

The above is modified from eth+ as LAN connections with the exception of VOip are all wireless

Combining the above it seems I should add:

iptables -I FORWARD -i wl0 -o tun+ -j ACCEPT

iptables -I FORWARD -i tun+ -o wl0 -j ACCEPT # make sure that wl0 and tun+ can "communicate"

iptables -I INPUT -i tun+ -j REJECT

iptables -I OUTPUT -o wl0 ! --dst 50.115.127.44 -j DROP # if destination for outgoing packet on eth+ is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects

# the above line can be duplicated for as many Air servers as you wish to connect to, just insert the appropriate Air server entry-IP8888888888888

then save the firewall, reboot and reconnect. (am unsure how to "make sure that wl0 and tun+ can "communicate"")

Hope this is correct. TIA!!!

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image
Sign in to follow this  

×
×
  • Create New...