Gre tunnel to protect IP.
-
Yes, I'm already doing that. Now I use NAT 1:1 or Outbound?
-
Is it working? Does the expected external IP show in test site?
-
I created the rule like this and it worked.
The only problem now is the ports are not working.
And they are open on the firewall. -
On remote host i recive the packets on wan interface.
If i change for the gre interface the packets not are sended
-
Ah, you need traffic to work inbound as well?
You captured that on the GRE interface? That's surprising if so. I might expect to see that on the WAN...
Anyway if you need inbound and outbound traffic then I would use a 1:1 NAT rule at the remote side instead of the outbound NAT rule.
You will also need firewall rules on the WAN there to pass whatever traffic you need.
And you will need a static route to 192.168.1.0/24 via the GRE gateway so it knows where to send traffic.Steve
-
Yes I want to open ports on the machine and they are available for that ip.
I did this on the remote host but it still doesn't work. In packet capture I analyze the gree interface (remote host) and nothing gets there.
Is there a better way to do what I'm trying to do?
Thanks for the help
-
The WAN rule there needs to be:
Source: any
Destination: 192.168.1.150
Destination port: 3389 (or an alias of whatever ports you want to allow)Steve
-
It worked, thanks a lot for the help.
Is there any better way to do this? It will be for VPS use.
What I would really like to do is add the public IP directly to the VPS.
Thanks again for the help, I really appreciate it. -
To use a public IP directly you would need to have a small subnet that is routed to you that you can then use internally.
Either that or bridge the connections so it appears as one layer 2. You might be able to do that with OpenVPN in TAP mode instead of GRE but I would not recommend it.Steve
-
@stephenw10 OK thank you. So in your opinion this is the best solution right?
-
It is for the way the IPs you have are provisioned, yes.
If you're able to get a routed subnet then a fully routed solution would be cleaner. You'd probably need to pay for a /29 though which you may not need.
Steve
-
@stephenw10 Understood! Thank you very much.
-
Hi @stephenw10 ,
I will probably buy a /28 since my clients have increased and I am using about 10 ips. Could you give me some tips on how to do "fully routed solution " as mentioned above. I would be grateful.
Thanks
-
You need to have a routed subnet. So that means the provider at the remote side needs to route the /28 to you via the WAN IP which must be in a different subnet.
Then you can route traffic to/from that subnet however you wish. Including routing it across the GRE tunnel and using it directly on clients at the local end.Steve
-
I've been having a problem which is high CPU utilization on the remote host. The system only has 1 vCPU 3.40Ghz but I think I must have something wrong. I had to check and in the traffic graph option the wan interface of the pfsense remote is using a lot of bandwidth and in the dashboard it doesn't happen.
I send the prints below so you can better understand the problem.Thanks
-
Hmm, curious. Those graphs should show the same data.
What are the IPs shown as generating the traffic there? .145 and .160?
Check the state tables. What are the states being created by that?
Steve
-
The ip .145 is the remote pfsense ip used only to access the pfsense graphical interface and to establish the gre tunnel with the local pfsense. The other ip's are from virtual machines that probably run game servers.
Thanks
States: https://pastebin.com/JzsHJezE
-
Hmm, all of those states are to/from one host at .160.
No traffic is show from .145 at all.
There is no GRE state on WAN and that should always be there.
Was the table filtered when you took that data?What is the WAN bandwidth at the local end? Or the bandwidth on GRE?
Steve
-
On the proxmox server the traffic seems to be clean and it's the only machine I have connected to the local pfsense so the problem I think must be in the pfsense. It looks like it's tripling the bandwidth coming out of the server inside the gre tunnel.
-
Mmm, but you're seeing ~25Mbps there. Check the history in Status > Monitoring for the GRE interface at each end. That should be showing the same thing.
