Project

General

Profile

Actions

Bug #3684

closed

Openvpn not routing incomming traffic correct when using tap device

Added by Lars Jensen almost 11 years ago. Updated over 10 years ago.

Status:
Rejected
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
05/30/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

Will try this again and it is NOT a config issue

I have 2 openvpn clients on my server 1 running with tun as device and 1 running with tap as device,

traffic coming from the outside to example port 53 using tun is routed correctly back over the openvpn client,

traffic coming from the outside to example port 53 using tap is routed over the default route and not the interface it is coming from, the only way I have found is to use redirect-gateway def1
this will create a route in the top of the routing table with 0.0.0.0/1 (tap gateway), but that should not be needed as traffic should be routed back over the same interface as it came in on.

And before you close it and say it will follow the route or reply-to rule then I can say it does not

from rules.debug:
pass out route-to ( ovpnc2 88.80.28.129 ) from 88.80.yyy.xxx to !88.80.28.128/25 keep state allow-opts label "let out anything from firewall host itself"

PRQTUNNEL = "{ ovpnc2 }"
pass in quick on $PRQTUNNEL reply-to ( ovpnc2 88.80.28.129 ) inet proto icmp from any to any keep state label "USER_RULE"
pass in quick on $PRQTUNNEL reply-to ( ovpnc2 88.80.28.129 ) inet proto tcp from any to $mail port $mail_server flags S/SA keep state label "USER_RULE: NAT ACCESS TO MAIL SERVER"
pass in quick on $PRQTUNNEL reply-to ( ovpnc2 88.80.28.129 ) proto { tcp udp } from any to 10.19.2.10 port 53 keep state label "USER_RULE: NAT DNS in PRQTUNNEL"

according to the first rule all trafic from 88.80.yyy.xxx should go to 88.80.28.129 that does work for out going traffic

according to the 3 pass in rules with reply-to ovpnc2 88.80.28.129 traffic comming in with that rule should go out over 88.80.28.129 that does not happen, it goes out over default gateway and that will never be a config issue.

Actions #1

Updated by Dmitriy K over 10 years ago

I confirm this bug is present since 2.2.

Tested on 2 setups.

very first setup and results:
1. I have bridged the following interfaces: LAN (172.16/16), OVPN TAP (172.16.1/16);
2. OVPN TAP clients was unable to web access to the gateway (172.16.0.200);
3. OVPN TAP clients was unable to access an Internet via gateway, but not permanently. Sometimes I was able to open few pages;
4. OVPN TAP are able to ping everything including gateway and any internet host;

second setup and results:
1. 2 pfsense routers (A and B) with 172.16/16 network.
2. "A" router has bridged LAN (172.16.0/16) and OVPN TAP ifaces;
3. "B" router has bridged LAN (172.16.10/16) and OVPN TAP ifaces;
4. "B" router connects to "A" router;
5. both routers can NAT outside a 172.16/16 network;
5. any PC from "B" network can't access (but can ping) "A" network gateway (172.16.0.200);
6. any PC from "B" network can't access Internet (but can ping) via "A" network gateway (172.16.0.200);
7. any PC from "A" network can't access (but can ping) "B" network gateway (172.16.10.200);
8. any PC from "A" network can't access Internet (but can ping) via "B" network gateway (172.16.10.200);
9. any PC from "B" network is able to connect to any PC from "A" network;

both setups are working on 2.1.x and doesn't work on 2.2.

Turning on a "Log packets matched from the default block rules put in the ruleset" option gives interesting log where lots of "<-LAN" packets to right destination are blocked even if "pass" rules are present for that case!

Sorry for my English.

Actions #2

Updated by Chris Buechler over 10 years ago

  • Status changed from New to Rejected

it is broken on 2.2 at the moment, that's #3760.

It does work where route-to/reply-to function correctly though. Just because those rules are in the ruleset doesn't mean they're the ones matching the traffic. Likely an OpenVPN group or floating rule overriding the interface-specific ones in OP's case.

Actions #3

Updated by Lars Jensen over 10 years ago

There is no other rules for the openvpn and no flowing rules,

I have tried to update to beta 2.2 and I have the same issues on that with only those rules configured

Actions

Also available in: Atom PDF