Project

General

Profile

Issue #3331

Forwarding Client Traffic: MASQUERADE is not applied

Added by Bruno Maire 8 months ago. Updated 8 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.7.2
Resolution:

Description

Hello,

Topology:
VPN-Client: RaspberyPi behind NAT.
VPN-Server: RaspberyPi with public IP
Both have only one ethernet connection on eth0

All traffic, except local, is sent from VPN-Client to VPN-Server.

On VPN-Server: All traffic from VPN-Client is sent to internet with private address of VPN-Client as source address.
Inserting the rules:
-A POSTROUTING -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE
Does not have any effect.

Any suggestions?

Best regards,
Bruno

server.zip (7.11 KB) server.zip Bruno Maire, 05.02.2020 16:14
client.zip (9.33 KB) client.zip Bruno Maire, 05.02.2020 16:14

History

#1 Updated by Tobias Brunner 8 months ago

  • Category set to configuration
  • Status changed from New to Feedback

I guess you wanted to use leftsubnet=0.0.0.0/0 on the server because currently the client only has access to the server's IP address (i.e. there is nothing to NAT as the client can't tunnel traffic to any external IP addresses).

#2 Updated by Bruno Maire 8 months ago

Thank you for the reply.
Sorry, but I don't understand the part "there is nothing to NAT as the client can't tunnel traffic to any external IP addresses".

The client will be behind a mobile router. The mobile router will get a private IP from the telecom provider.
The goal is:
- to route all traffic from the client though the VPN to the internet and back
- to expose the client behind NAT to the internet. In sort that the client is able to accept incoming connection through the VPN.

#3 Updated by Tobias Brunner 8 months ago

Sorry, but I don't understand the part "there is nothing to NAT as the client can't tunnel traffic to any external IP addresses".

Your config is wrong. You only tunnel traffic to your server's IP. So there is nothing to NAT as tunneled traffic (which can only address the server's IP) is delivered locally.

The goal is:
- to route all traffic from the client though the VPN to the internet and back

Exactly, your config doesn't do that. Just fix it.

- to expose the client behind NAT to the internet. In sort that the client is able to accept incoming connection through the VPN.

That requires additional config, the MASQUERADE rule won't forward traffic for unknown NAT mappings (i.e. traffic has to be initiated by the client).

#4 Updated by Bruno Maire 8 months ago

The goal is:
- to route all traffic from the client though the VPN to the internet and back

Exactly, your config doesn't do that. Just fix it.

Currently I am working on the part to send the clients traffic through the VPN to the internet. This works so far.
The problem is that the clients' IP private is sent as source IP. The intention is to change the source IP to the servers public IP with MASQUERADE (or SNAT).
eg.
- client ping strongswan.org (152.96.80.46)
- packet is sent through VPN
- currently on server the packet is sent from 192.168.8.101 to 152.96.80.46 to the internet (it will never return with this source address)
- with MASQUERADE (or SNAT) I expect the packet to be modified to be sent from 37.209.178.232 (public IP of server) to 152.96.80.46 (This is the part which doesn't works yet)

Routing the packets back is to do later.

#5 Updated by Tobias Brunner 8 months ago

Currently I am working on the part to send the clients traffic through the VPN to the internet. This works so far.

It's not. At least not with the config you have above.

- packet is sent through VPN

It's unlikely that that's the case (check the status output or the log, there was no tunnel negotiated that covers packets with such a destination address).

- currently on server the packet is sent from 192.168.8.101 to 152.96.80.46 to the internet (it will never return with this source address)

Are you sure? How did you check that there is such a packet on the server?

#6 Updated by Bruno Maire 8 months ago

Wireshark on the server:

Frame 225: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
Ethernet II, Src: Cadant_5b:bc:41 (00:01:5c:5b:bc:41), Dst: Raspberr_6c:77:ea (b8:27:eb:6c:77:ea)
Internet Protocol Version 4, Src: 192.168.8.101, Dst: 152.96.80.46
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x819a [correct]
    [Checksum Status: Good]
    Identifier (BE): 3498 (0x0daa)
    Identifier (LE): 43533 (0xaa0d)
    Sequence number (BE): 1 (0x0001)
    Sequence number (LE): 256 (0x0100)
    [No response seen]
    Timestamp from icmp data: Feb  5, 2020 18:27:51.286247000 CET
    [Timestamp from icmp data (relative): -0.097687719 seconds]
    Data (48 bytes)

#7 Updated by Tobias Brunner 8 months ago

Unless your client routes traffic via your server anyway, your config, log and status output doesn't support this.

#8 Updated by Bruno Maire 8 months ago

Where did I go wrong?
Which of the examples can I take as a base?

#9 Updated by Tobias Brunner 8 months ago

Where did I go wrong?

I told you in my first comment (leftsubnet=0.0.0.0/0). You can keep rightsubnet as it is or set it to the client's private IP or subnet, or you remove it and switch to virtual IP addresses (like a proper roadwarrior config, see UsableExamples).

#10 Updated by Bruno Maire 8 months ago

Thank you very much.
I somehow didn't understood it on your first reply. Sorry.
On server
- added (leftsubnet=0.0.0.0/0) --> VPN is working
- (rightsubnet=0.0.0.0/0)
-- can ping server from client
-- can ping client from server
-- cannot ping strongswan.org (152.96.80.46) from client
- (rightsubnet=192.168.8.101/32) client private address--> access to internet from client is working via VPN

Port forwarding for VNC works with:
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 5900 -j DNAT --to 192.168.8.101:5900

Port forwarding for Echolink does not work with:
iptables -A PREROUTING -t nat -i eth0 -p udp --match multiport --dport 5198,5199 -j DNAT --to 192.168.8.101

The problem is, that the Echolink protocol expects the original sender IP and not the VPN server IP.
I tried to mark these packets in the mangle table without success (https://www.sparksupport.com/blog/2010/10/02/application-based-routing-in-linux_port-based-routing/)
How do I tell strongswan to keep the original sender IP in sort that the client will reply directly to original sender IP and not to the VPN server IP?

Also available in: Atom PDF