thanks for the fast answer but the tunnel is established succesfully.
ah ok, thanks
I also think that this has to be a NAT Problem and tried different rules.
Green IP (192.168.5.0.x) has to become a local subnet IP (172.21.105.x) which is than sent over IPSec to the destination and back again.
So 2 rules should be enough, yes.
Do I need extra routes in order to get this to work?
I do not think so, but I speak of what I do not understand well enough. My reasoning is the following: the traffic originating from the other side of the tunnel (172.2.105.X) will be remapped to a subset of your green network, say 192.168.5.192/26 by SNAT, as well as the traffic originating from your side of the tunnel in that green sub-net should be sent back to the other side (172.2.105.X). This should be enough for a successful routing on both sides.
EDIT: maybe even one rule should be enough, without using a subset of your network? In the hub&spoke you needed two rules because you wanted to connect 2 network through a central location. But in your case?
If you manage to solve the problem would you write a short “how to”, to leave some breadcrumbs for other people in the future?
1 Like
The Problem here is that both subnets 192.168.5.x and 172.21.105.x are on our site.
192.168.5.0/24 is our green network and 172.21.105.0/24 is the local Subnet I entered on our site of the IPSec configuration and is only configured here. Otherwise 172.21.105.0/24 does not exist on our Site.
The Subnet from Site B is 10.2.44.0/24.
I would need NATing on our Site between 192.168.5.0/24 and 172.21.105.0/24.
I have a similar configuration:
Setup von Site B:
/etc/sysconfig/firewall.local
Change X to a free IP. The Router 172.21.105.1 must route the Subnets 192.168.5.0 and 10.2.44.0 to X. And than your IP-Sec-Setup will work.
3 Likes
Sry for the confusion I may have caused.
I try to explain it again.
Site A
Green 192.168.5.0/24
IPSec config:
local subnet: 172.21.105.0/24 (which is only configured here, and otherwise not existing in our network, so no gateway…)
RemotHost/IP: x.x.x.x
remote subnet: 10.2.44.0/24
Site B:
green: 10.2.44.0/24
IPSec config:
local subnet: 10.2.44.0/24
RemotHost/IP: x.x.x.x
remote subnet: 172.21.105.0/24
Site B cannot enter 192.168.5.0/24 as there remote subnet as this subnet is also part of their network infrastructure.
How it should be:
192.168.5.10 sends a request to 10.2.44.10.
192.168.5.10 → needs to know that 10.2.44.10 can be reached over IPSec Tunnel.
192.168.5.10 needs to become e.g. 172.21.105.10 and sends the request over IPSec tunnel.
When the response comes back 172.21.105.10 must be translated back to 192.168.5.10.
I guess that I not only need NATing Rules on our site A to translate 192.168.5.x to 172.21.105.x before sending trough the IPSec Tunnel.
And I can only make changes to site A and not B.
Thanks for your reply.
I don’t have a gateway for 172.21.105.0/24
Does Site B have access to site A 172.21.105.0/24? The problem is only on your side, meaning that you cannot route 10.2.44.0/24 from site B?
As far as i know Site B is configured to accept requests from 172.21.105.0/24 and sends it back.
They have more costumers with this set-up so it should be ok.
So yes, i guess the problem is only on our site A.
I guess if I could set this rule everything could work.
1 Like
I think it’s what @steven was suggesting in post 12. Those command should create the network and bridge it to the green interface. After that, it should be visible in web user interface.
2 Likes
Sorry, but i can’t understand, how your 172.21.105.0/24 network can work without a gateway?! What is the network configuration on a client in this network (IP, DNS, GW)?!
And the most important: How can 192.168.5.0/24 communicate with 172.21.105.0/24 in your setup?
How ever: IPfire must be a part of the 172.21.105.0/24 network. If that subnet really doesn’t have a gateway, which I don’t think so, then ipfire will become the gateway for that subnet with my config of the screen on site a without the second route-line. Setup the IPfire-IP of 172.21.105.0/24 as gateway on the 172.21.105.0/24 clients. Then you can tunnel with the respective remote subnets 10.2.44.0/24 and 172.21.105.0/24 and it will work. If you also wan’t a connection from 10.2.44.0/24 to 192.168.5.0/24, you must setup a second tunnel with this remote-subnet and it will work.
No, unfortunately it is not visible in the web interface, but it is there and can be used as a remote-subnet in the ip-sec-setup and Ipfire routes it accordingly.
1 Like
Hi,
i cannot chnage the settings on site B.
I have set up IPSec tunnels before with the settings you mentioned and they were all working.
1 Like
Hi Steven,
the thing is that site B is expecting that traffic over the Tunnel is coming from 172.21.105.0/24 and I sadly cannot change this.
Our Setup has only green 192.168.5.0/24 and red.
That’s exactly the thing, how can it work without having a gateway.
It won’t I guess. That’s the Problem. Is this Setup even possible with IPFire?
There actually won’t be any client with the address 172.21.105.x.
This subnet 172.21.105.0/24 is only needed for the traffic through the IPSec tunnel.
I now was thinking of making a vlan with Blue over the green NIC.
The new Blue VLAN would have 172.21.105.0/24.
is it possible to make a IPSec tunnel with blue on site A and route the traffic from green over blue to site B?
What a bullsh*t.
If 172.21.105.0 has no clients, with what should the Site B communicate?!
You must change the remote-subnet to 192.168.5.0 on Site B or change your green network on Site A from 192.168.5.0 to 172.21.105.0. How else would Site B know where 192.168.5.0 is?!
@steven Can I ask you a question, since my understanding of routing is really poor? OP has made the point that SIte B is administered by others and they have chosen (and I presume imposed to OP) to establish tunnel with site A excluding its green network because it is mapped to 192.168.5.0/24 which is a network range also present on site B. This implies some sort of problem that requires a clear separation between the local network on SIte A and the local network on site B.
My question is: does it? Is there really a conflict or a problem? To me it looks like this is perfectly compatible! And with “this”, I mean having similar network ranges at both ends of a tunnel.
Indeed it is a bullsh*t but unfortunately this is the way it has to be. I have no control over site B and they are unwilling to change anything on their site.
So Site A 192.168.5.10 sents a request to 10.2.44.10.
192.158.5.10 has to become e.g. 172.21.105.10 on site A through NATing
10.2.44.10 sents the response back to 172.21.105.10 so site B knows where to sent the response.
Is this somehow possible to do with IPFire or not?
I’m running out of ideas how I can implement this with only one green network.
Could it be possible to do this with 172.21.105/24 being VLAN Blue or are there to many restrictions between green and blue?
Is blue even allowed traffic through IPSec?
I read for OpenVPN you have to configure specific routes in the openvpn config files in order to let blue through.
Sadly true.