Modify

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1318 closed bug (support)

OPENVPN | wrong client source ip address

Reported by: FM Owned by:
Priority: normal Milestone:
Component: unknown Version: Other
Severity: unknown
Cc: Hardware: 2.0n (FON2300)

Description

Hi,

My fonera IP is 192.168.1.A and the openvpn network is 10.8.0.x.

When I try to connect to something that is on the other side of the VPN it sees the connection coming from the source IP 192.168.1.A and not from the client source IP.

I would like that the original source IP would become visible to the other machine.

Any hint?

Thanks

Attachments (0)

Change History (9)

comment:1 Changed 5 years ago by matthijs

From the mail conversation preceding this bug report:

From the top of my head, this happens because the VPN is routed onto your LAN network, but anything that is routed from VPN or LAN onto WAN gets NAT applied.

I think the only way around this now is to put your Fonera into bridge mode instead of regular DHCP mode (as it is probably in now).

It's already in bridge mode.

Hmm, that's weird.

I just doublechecked some code and:

  1. NAT is only set for packets going out of the WAN interface
  2. In bridge mode, the WAN interface is disabled and everything happens on the LAN interface.

This would suggest that no NAT can be applied in bridge mode, but you're seeing it nonetheless.

comment:2 Changed 5 years ago by matthijs

  • Resolution set to support
  • Status changed from new to closed

I had a go at reproducing this and got the same behaviour. I also found out what is happening, though I'm not so sure it's really a bug or easily solvable.

I found that in bridge mode, the firewall is configured to do NAT on packets going out of the LAN (bridge) interface (instead of the WAN interface as normal). This also makes sense, since in bridge mode, the Fonera is _not_ the default gateway for the LAN network. This means that if it sends out packets onto the LAN network using a source address of e.g. 10.8.0.x, the recipient of that packet will send its reply to gateway instead of the Fonera, and the gateway doesn't know how to handle this.

This means that there's really two problems to handle:

  1. Tell every other client (or perhaps the default gateway) that the 10.8.0.x network is to be reached through the Fonera (e.g., using a static route).
  2. Prevent the Fonera from doing NAT on VPN packets.

I'm not sure how to achieve the second one in a sane way. The easy way is to disable NAT altogether, by commenting out trunk/fon/fonbase/files/lib/fon/config.sh:#L80. However, this will also break the public wifi hotspot (unless you also configure a static route for 192.168.182.x I think).

It would be better to disable NAT just for packets coming from the VPN, I'm not so sure that is possible or how to achieve this... (trunk/openwrt/package/firewall/files/uci_firewall.sh might help here, haven't looked at it closely yet).

Perhaps this gives you enough info to make things work?

In any case, I don't think this is a bug in the Fonera. At the very least it could be a feature request for more configurability, but the current behaviour makes sense and makes things work for most people. For this reason, I'm closing this ticket, but feel free to post more comments if you have further questions on how to make this work for you.

comment:3 Changed 5 years ago by FM

I'll try to disable NAT completly.

When you say that it would break the public wifi hotspot I would fix it if I set a static route for the .182 network at my Default Gateway right?

Thanks

comment:4 Changed 5 years ago by matthijs

I _think_ that would fix public wifi again, yes. However, there might be other firewalling rules that could cause problems, I'm not entirely sure it will work. Best just try it :-)

comment:5 Changed 5 years ago by FM

Ok,

Commented line 80 and It's almost doing what I want :)

Now the source address is 10.8.0.client however I would like the source IP to be 192.168.10.client which is its IP address on the other network side...

comment:6 Changed 5 years ago by FM

I mean 10.8.0.client is not really the client.

This is a point to point deployment with the fonera beeing the server and a WRT54GL beeing the client.

All the people that connects to WRT54GL and try to reach the fonera side of the network get Its source IP address as beeing the WRT54GL...

comment:7 Changed 5 years ago by matthijs

Hmm, you keep making things more complicated ;-)

I think what's needed for that is:

  • Add a static route on the Fonera that routes 192.168.10.x through the OpenVPN connection.
  • Add a static route on the network around the Fonera that routes 192.168.10.x to the Fonera (I think this can replace the 10.8.0.x route you already added).
  • Configure your WRT54GL to not apply NAT to the packets going over the VPN (I think that's what's happening now).

comment:8 follow-up: Changed 5 years ago by anonymous

I checked IPTABLES briefly and I did not see any NAT on VPN traffic.

But I'll double check.

comment:9 in reply to: ↑ 8 Changed 5 years ago by anonymous

I think I had something similar set up a year or so back. Basically I had my Fon router set in bridge mode and manually configured it to connect to my works Openvpn server and it linked the networks up without using NAT.

Work 10.1.1.0 |openvpn 10.8.0.0|home 192.168.10.0

At work I had to create a static route on our router so anything going to 192.168.10.0 would be routed to the openvpn server and the same thing at home, so everything going to 10.1.1.0 would be routed through the fonera. I can't remember all the steps but I know I had to enable forwarding on the openvpn server (ubuntu) and also add the following to the openvpn config file

push "route 10.1.1.0 255.255.255.0"

on the fonera I edited the /etc/config/firewall file and added/changed (I can't remember) the following

config 'zone' 'vpn'
        option 'name' 'vpn'
        option 'input' 'ACCEPT'
        option 'output' 'ACCEPT'
        option 'masq' '0'
        option 'forward' 'ACCEPT'

I also create a vpn.sh to assign TAP0 to the VPN zone.

#!/bin/sh
logger "adding tap0 to firewall zone vpn"
iptables -A input -i tap0 -j zone_vpn
iptables -I zone_vpn_ACCEPT 1 -o tap0 -j ACCEPT
iptables -I zone_vpn_DROP 1 -o tap0 -j DROP
iptables -I zone_vpn_REJECT 1 -o tap0 -j reject
iptables -I zone_vpn_ACCEPT 1 -i tap0 -j ACCEPT
iptables -I zone_vpn_DROP 1 -i tap0 -j DROP
iptables -I zone_vpn_REJECT 1 -i tap0 -j reject
iptables -I zone_vpn_nat 1 -t nat -o tap0 -j MASQUERADE
iptables -I PREROUTING 1 -t nat -i tap0 -j zone_vpn_prerouting
iptables -A forward -i tap0 -j zone_vpn_forward

and then added the following two lines to my fonera's openvpn client config, so it would run the script when the openvpn connection was made (I probably should of made a down script too, but I wanted it to be always connected)

script-security 3 system
up "/bin/vpn.sh"

Again this was a long time ago and may not be what you want, but may be somewhat helpful, So I thought I'd share what I remember :)

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.