I am trying to get server 1 to talk to a service in the 170.x.x.x network while appearing to originate from the ip address 10.42.60.164. Using Speedfusion and nat across the balance 210 i can ping across to the 170 network from the FusionHub device. I can’t figure out how to get server 1 to talk to the balance 210 much less the 161 gateway to get across to the 170 network.
I’m not married to the 10.55 virtual network but kept getting route errors on the Speedfusion connection when i tried to use 10.42.60
If anyone has attempted something similar, i could use some direction because i’m not making any headway.
Ok… Now, this diagram tells us some new things, but there are still some missing pieces.
What is 10.42.60.164? That is so critical that your traffic needs to seem to source from that IP? and that cannot change?
What is the way the Balance 210 actually connects to the internet? You show 2 lines, but only list 1 IP address. LAN? WAN?.
What is the default route (and route to 170.x.x.x) on the Sever 1?
What does the hughesnet gateway do?.. does it NAT? does the 170.x.x.x network see a 10.X.x.x IP? or a public IP. This is a private hughesnet connector?
I guess I missed that you are now trying to use a FusionHub for routing rather than IPsec.
So some of my questions are answered, Servers only expect one router, so you want to put the fusion hub out in a network all on its own, it can’t share the subnet unless you use static routes on every server in the local network.
I discuss the reasons in this thread (AWS, but the networking part is the same anywhere).
https://forum.peplink.com/t/no-aws-outbound-traffic-on-fusionhub-subnet-to-max-transit-(speedfusion-connection-is-established)/61f190eb4792ea21a752a384/10
You are running the FH in forwarding mode, not NAT right?.
So you need a new virtual network. 10.55.57.0/24… put the FusionHub in that. Tell the Azure router fabric that 10.42.60.0/24 is routed via 10.55.57.5 (new FH IP). Also add 170.x.x.x/? via static route.
Add a static route for 10.55.56.0/24 via 10.55.57.1, on the FH and make sure that it gets added to the SpeedFusion list.
with all of that the traffic should now be on the 10.42.60.0 network.
It could be with the NAT address of the B210… or the native IP of Server1. So we are back to: what is critical about 10.42.60.164, and what NATing is the Hughesnet SAT system doing?
I put FH in forwarding mode and lost access to it. I will restart it in a gateway subnet. The balance is connected to the internet on WAN and LAN to the huesnet router.
That stupid 164 address is critical because it’s part of how the system that it will be interfacing with authenticates. It is assigned by a government entity so they won’t be changing how this works to make my life easier.
What happens behind that 161 address is something of an enigma to me i just have specific instruction on the originating IP address. We are attempting to replace an on prem server connected directly to that huesnet satellite router.
I have my server still on 10.55.56.4 the fusionhub is now on 10.55.57.4.
On subnet 10.55.56.0 i have a route defined 10.42.60.0/24 ‘next hop type’ virtual appliance 10.55.57.4
the NIC for the fusionhub is set to forward.
This is the wan on the fusionhub
Static route on the fusionhub
VPN profile on the fusionhub
I am still unable to get from the server across the fusionhub. I don’t know if the issue is in azure or the fusionhub. I turned on any to any on the fusionhub firewall and am not seeing any activity recorded on the firewall logs so it makes me think i’m missing something on the azure side.
That looks good, but I would turn off “apply NAT on remote peers’” since we don’t want NAT unless we expressly decide on using it there…
So next we need to check connectivity. Can you ping from the server to the FusionHub?. Then to the LAN of the Balance.
Next, what are the networks shown in Speed Fusion… each side should say the networks that are advertised and routed.
If no pings work at all then we need to run a packet capture on the FH to determine if the packets get to there, or if they are getting lost on the way back.
We have other architecture capabilities, we could run a layer2 VLAN across the SF tunnel, but then we need to know who is managing DHCP in the 10.42.60.0/24 space. You can’t turn off DHCP in Azure. Could you use a different cloud provider like Vultr?. They allow clean virtual networks.
Given the specific 10.52.60.164 requirement a peplink router might not be the best solution for this… a Juniper SRX, or other full feature firewall/router would ipsec to azure and allow NAT by explicit IP. Are you using Multi WAN or other peplink features?
In addition what other systems aree in the 10.42.60.0/24 space?..
I I turned off the apply nat on remote peers.
I can ping the fusion hub from the server. I can’t ping from the server to the lan side of the balance.
This is what is on the fusionhub
This is what is on the balance side.
the 10.42.60.0 space is all statically assigned.
There is only one other device on 10.42.60.163
I can’t move to another provider because this is only authorized for use in azure gov.
I’ll working on getting packet capture to the fusionhub
Believe me, i have asked for a different piece of hardware. These peplink routers are awesome for what it is designed for but you ask it to do anything just a little bit different than that and you wind up spending days and begging for help in forums.
Ok,
Your routes in Azure are not getting sent to the Balance… So the balance doesn’t know how to reply.
On the FH
Open Network → Ospf → Click on area 0.0.0.0 and add WAN into the OSPF settings, and make sure that static route advertising is enabled as well.
OSPF status should show all of the routes:
I am asuming that you have NAT on the Balance PepVPN side… and hence the 10.42.60.164 IP… which is nice for you… I’m not sure it will be stable, if it isn’t I can suggest that you move the 10.42.60.164 to a WAN port… rather than lan. . NAT out WAN is always static and stable.
This is what OSPF is showing.
but the only thing in remote networks is the static route I have on the balance.
Ironically, i initially was trying to route wan1 to wan2 and couldn’t get that to work.
Yes, you can expand the blue > and see those are “remote” networks…
Now look at the same screen on the Balance, and its SF status… you should now see the 2 Azure networks.
If that doesn’t work, turn off the SF tunnel NAT at the balance and see what we get then… NAT may cancel OSPF routes.
So turning off NAT worked for getting the route advertised to the FusionHub
on the balance the route is showing inactive?
I’m unable to ping across the pepvpn from fusionhub to the 10.42.60.0 addresses from wan, lan, or pepvpn.
from the balance, i can ping the wan address of the fusionhub from the pepvpn interface (10.55.57.4) but not the server (10.55.56.4)
nothing about this is making sense yet
In times like this there is one thing we have missed and once we find it, we go “oh, of course, it was that”. but until you find the issue, it is inexplicable.
I think we are back to packet captures… tcpdump or wireshark removes questions, either the packet passes the port or it doesn’t.
Now you have removed all of the ipsec config in azure right?. No lingering routes for 10.42.60.0 other than the 1 static one we put in.
It is that Inactive: route that vexes me. I can only see inactive routes on my secondary tunnels, none of my meshed Fusionhubs (that have all transit routes) are listing “inactive” That really implies to me that there is something configured to use 10.42.60.0/24 on the FusionHub… Is there any configuration of that /24 on the FH?.. ipsec?. LAN?. static routes ? etc…
Finally got this working. It was the azure network security blocking traffic destined for the balance network. I set the balance back to NAT and traffic is flowing both directions and looks like it’s originating from the correct IP. Thanks so much for all the time looking over this issue with me.
Glad you found it… and where packet captures can save you time… a capture at the Fusion Hub would have shown the traffic not reaching that interface and kept you out of debugging the issue on the Peplink side. Once networking is weird, I switch right to tcpdump.
