Tunnel GRE from linux server to pfsens
-
There they are using an IP that is in the same subnet as the VPS public IP. That means they cannot route it and have to bridge the interfaces at both ends to create a single layer 2 segment.
So there they used OpenVPN in TAP mode a bridged it.You don't need to do that because your additional IP is not in the same subnet. You can just route it to the VM directly. But you still need to use a private subnet between pfSense and the VM to route it across.
-
Hello,
How can i create that route to GRE.
If i use VLAN 201 - 10.0.201.0/24
I need to configure the ip as alias and made nat translation ? Just that? -
You can use NAT and put the IPAlias on the firewall.
Or you can put the public IP on the VM directly as a virtual IP and route to it in pfSense. Which is what I thought you are trying to achieve.
-
Or you can put the public IP on the VM directly as a virtual IP and route to it in pfSense. Which is what I thought you are trying to achieve.
You mean configure 198.x.x.x directly in VM and some how route in pfsense? How should i do that?
-
You have to add it to the VM as a virtual / secondary IP. Then add a static route in pfSense to that IP via the private IP on the VM.
-
Hello Again,
Sorry for delay.
I've mantained the configuration in Linux server, in pfsense i made this configuration:Created a VLAN with gateway so i can reach the gateway localy (?)
Created a VirtualIP with ip i wan't:
And route it to GRE Interface:
Config in VM:
It seems i made something wrong :/
-
GRE is not TCP neither UDP, not ICMP.
The network connection is done via the GRE protocol (IP protocol number 47. For more information, refer to Wikipedia: List of IP protocol numbers. Since GRE is an IP protocol, it is not based on either TCP or UDP and has no concept of ports. It is an IP protocol by itself.
So, when I see this :
that that rule will never match ;)
-
@Gertjan Thank you for reply, i didn't know that. Already fix the rule.
-
@Jsetive said in Tunnel GRE from linux server to pfsens:
They have one guide
If you have NAT rules on one side of your tunnel, remember to chose 'GRE' as the protocol as well.
-
No you should not have a gateway on the VLAN201 interface directly.
You will need a gateway but you should add it separately and it should be the VM internal private IP.
You need to add a static route to 198.x.x.40 via that gateway.
You should not have a VIP on pfSense. You need to add 198.x.x.40 on the VM dircetly so you can route to it.
The policy route should work OK for outbound traffic.
-
@stephenw10 said in Tunnel GRE from linux server to pfsens:
You will need a gateway but you should add it separately and it should be the VM internal private IP.
Im confuse, you mean, i need to create a "custom" range to this vlan (eg 172.16.201.x/24) and the gatewa on VM will be that?
In vm i configure:
IP 172.16.201.40
Nmask /24
GTW 172.16.201.254Then i create a static route to 198.x.x.40?
-
Yes, that would work. The static route in pfSense would then be to 198.x.x.40 via 172.16.201.40.
-
I know this is not the same issue, tell if i need to create other topic.
I can't get DHCP from this VLAN, i CAN GET DHCP from VLAN.I've created VLAN 30 but still not getting ip:
VLAN 30 (not working):
VLAN 200 (working):
-
Did you enable DHCP on the new interface? Servcies > DHCP Server > VLAN30
-
-
@Jsetive said in Tunnel GRE from linux server to pfsens:
VLAN 200 (working):
I've a small test for you
On "VLAN 200", remove temporary all firewall rules. Empty the list.
Test your "VLAN 200" again : when you connect a device, it will get a DHCP lease !
When the DHCP server is activated, there will be 'hidden' firewall rules that accepts DHCP traffic.
Check the firewall rules for yourself : /var/rules.debug
Conclusion : the GUI firewall rules have no impact on the functioning of the DHCP server on that interface - afaik, the "the shoot in the foot" situation isn't possible. (although people tend to find out new ways to make live harder every day ^^)About your "VLAN30" : use Diagnostics > Packet Capture, select the interface (VLAN30) and hit start.
Now, connect your device on that VLAN30.
The question is : does the packet capturing shows you the DHCP packets ?
I presume you know how to recognize them.Another suggestion : switch from Kea to ISC and retry.
-
Then I would guess it's an issue with the VLAN tagging in whatever is connected to it. Probably a switch.
-
@stephenw10 @Gertjan
Thank you both for your reply.Check the firewall rules for yourself : /var/rules.debug
This file doesn't exist in my machine in that path.
About your "VLAN30" : use Diagnostics > Packet Capture, select the interface (VLAN30) and hit start.
Theres no packet in capture, can't see nothing:
(Untagged):
(Tagged):
Another suggestion : switch from Kea to ISC and retry.
I didn't tested change because others VLANs is pooling ips. but i tested and didn't worked as well. When i change VLAN in vm it get instantly the ip, when i change to VLAN 30 i get 169.254.x.x
Then I would guess it's an issue with the VLAN tagging in whatever is connected to it. Probably a switch.
Well i can agree with that, but the config is the same in pf and in switch for all VLANs, and other VLANs getting the ip, here is the config in port:
-
So port 4 is connected to pfSense there? You have VLAN 30 untagged on some of the other ports? Where the clients are attached?
@Jsetive said in Tunnel GRE from linux server to pfsens:
Check the firewall rules for yourself : /var/rules.debugThis file doesn't exist in my machine in that path.
That should be
/tmp/rules.debug. -
So port 4 is connected to pfSense there?
Yes, Port 4 is connected physically to pfsense then in proxmox choose which vlan i want to use in VM.
You have VLAN 30 untagged on some of the other ports?
No, it is tagged
Where the clients are attached?
Pfsense lead all dhcp and manage VLANs then a connect to switch where i tag all vlan in port 4 where are used in proxmox.
That should be /tmp/rules.debug.
