pfSense VPN tunnel traffic. Site A to Site B working, but nothing from Site B can get to Site A.
I have an IPSEC VPN tunnel configured between Site A and Site B. The tunnel is up and functioning fine. I am able to connect from Site A to Site B fine and interact with the mainframe software fine with a telnet connection. However the Printer at Site A is not being communicated with from Site B when inside of the mainframe connection (it has been working fine for several years until the firewall died and I just replaced with a pfSense firewall).
I have an IPSEC firewall rule for Source of any and Destination of any (Source *, Destination *) and that seems to be what allowed the tunnel to come up to begin with.
I am using pfSense and need to figure out what I need to do in order to get this working. From Site B, the client has tried telnetting back to port 80 to the Site A local lan printer IP and it's not working. Telnet from site A which is the local network for the printer on port 80 works fine.
It's probably something to do with NAT but I don't want to mess things up!
I have an IPSEC firewall rule for Source of any and Destination of any (Source *, Destination *) and that seems to be what allowed the tunnel to come up to begin with.
I am using pfSense and need to figure out what I need to do in order to get this working. From Site B, the client has tried telnetting back to port 80 to the Site A local lan printer IP and it's not working. Telnet from site A which is the local network for the printer on port 80 works fine.
It's probably something to do with NAT but I don't want to mess things up!
ASKER
Bembi,
I briefly mentioned this but I'll go into a little more detail.
The VPN tunnel from Site A to Site B had already been working prior to this for almost 10 years.
Site A had an Cisco ASA 5505 die on them and I replaced it with a pfsense box and plugged the VPN tunnel info back in and the tunnel came up pretty much immediately. I thought I was done at this point but the printer has been an issue since then. I've made sure I can access the printer on the local Site A subnet and it's fine. I asked customer to telnet to port 80 from site B server and it cannot get to it.
I'm at a loss on what I can check next.
BTW, what you are saying makes sense but this has been working until the ASA at Site A went out.
Also, They have a Site C, D, and E that also connect to Site B and I had them telnet from Site B to Site C on port 80 and it opens up fine...
I'm hoping I didn't confuse you on my response :)
I briefly mentioned this but I'll go into a little more detail.
The VPN tunnel from Site A to Site B had already been working prior to this for almost 10 years.
Site A had an Cisco ASA 5505 die on them and I replaced it with a pfsense box and plugged the VPN tunnel info back in and the tunnel came up pretty much immediately. I thought I was done at this point but the printer has been an issue since then. I've made sure I can access the printer on the local Site A subnet and it's fine. I asked customer to telnet to port 80 from site B server and it cannot get to it.
I'm at a loss on what I can check next.
BTW, what you are saying makes sense but this has been working until the ASA at Site A went out.
Also, They have a Site C, D, and E that also connect to Site B and I had them telnet from Site B to Site C on port 80 and it opens up fine...
I'm hoping I didn't confuse you on my response :)
As you replaced the ASA by pfsense device at location A....
There is no change at location B, right?
Possibly you need an additional FW path from the VPNTunnel to the A network in th sfsense device?
There is no change at location B, right?
Possibly you need an additional FW path from the VPNTunnel to the A network in th sfsense device?
YOU may try to tracert from B to A to see, if the trace touches your sfsense.
ASKER
I will have them do that tomorrow. There has been no change at all to site B, only to Site A (firewall change). Just for the hell of it I went ahead and added a static route to site A and used the internal LAN IP of firewall as gateway to the site B network. Don't think that's gonna do anything though. They will test that tomorrow for me
ASKER
Still not working even with adding static route in. I'm sooooo confused.
If anyone has any recommendations, please let me know.
If anyone has any recommendations, please let me know.
Have you tried to tracert from B to A possibly to see if the traffic passes the vpn tunnel?
ASKER
I've requested a traceroute.
Do you think I need to change pfsense NAT to hybrid and then specify a rule so that when traffic goes across it doesn't NAT? Kind of like a NAT Exempt rule on a Cisco (NO NAT). I'm not sure how to configure that just yet, but I'm about to read to see how to do it.
Do you think I need to change pfsense NAT to hybrid and then specify a rule so that when traffic goes across it doesn't NAT? Kind of like a NAT Exempt rule on a Cisco (NO NAT). I'm not sure how to configure that just yet, but I'm about to read to see how to do it.
ASKER
Traceroute doesn't go anywhere. It basically just shows each hop with ****** across it until it's canceled.
ASKER
Had them traceroute from Site B to Site C and it traceroutes fine. One-Hop. Like I said, this was working before the swap out of firewalls. I don't know what else to do except maybe try some type of NO NAT rule to see if that works, not sure how to do that though
Lets say, NAT is used, when you use not private networks like 10.x.x.x, 172.16.x.x - 172.32.x.x, 192.168.x.x behind a public IP. As private addresses are not routed by any public router, they have to translated to a public IP so that other public services know how to route back.
Therefore NAT happens only from and to the internet (between private ans public networks).
For internal connection, there is no need for NAT and even not recommended. Inside your network, you can route whatever you like. You just have to make sure, that the privat addresses are not blocked by default.
Tracert:
traceroute just pings every hop and tries to get back the name.
If ping is disabled on a router, the traceroute passes, but doesn't respond on the ping.
Also ping is usually only switches off on external IPs or public visible IPs.
If you create a VPN Tunnel, it act more or less like a cable, but the router has to decide, what has to pass the vpn tunnel and what not. It is usually done if you setup a VPN tunnel, but for a bidirectional connection, you need settings on both side.
As ping tracerout works from A to B, the route is possibly set by the VPN Configuration.
As ping / traceroute doesn't work from B to A, it looks like that the B router doesn't know, where to send the packets.
Some router also allows the selection of biderectional tunnels, so they are able to configure both sides by exchaning routing information. But this works (if it works) usually only for routers from the same type or manufacturer.
As your devices are different, you may have to setup each side individually.
As you said, there was a tunnel before with ASA devices, and you replaced one site (A), it may be possible that the old tunnel configuration still exists on the other site (B) and this tunnel configuration doesn't have a counterpart and therefore sends everything into the nowhere.
So have a look at site B, if there is still am old VPN Tunnel / routing configuration to A, possibly you have to delete it and recreate it again. Sometimes it is just only needed to correct some settings.
Maybe your other VPN Tunnels give you a clou, what you have to setup on site B to route back to site A. As B is also connected to C,D,E, the settings for A should be similar just with different IP Adresses.
From the general perspective...
Router A has to know which targets are behind network B. Also router B has to know, which targets are bedind network A. Pring / tracert is the proof, that routing works fine.
Therefore NAT happens only from and to the internet (between private ans public networks).
For internal connection, there is no need for NAT and even not recommended. Inside your network, you can route whatever you like. You just have to make sure, that the privat addresses are not blocked by default.
Tracert:
traceroute just pings every hop and tries to get back the name.
If ping is disabled on a router, the traceroute passes, but doesn't respond on the ping.
Also ping is usually only switches off on external IPs or public visible IPs.
If you create a VPN Tunnel, it act more or less like a cable, but the router has to decide, what has to pass the vpn tunnel and what not. It is usually done if you setup a VPN tunnel, but for a bidirectional connection, you need settings on both side.
As ping tracerout works from A to B, the route is possibly set by the VPN Configuration.
As ping / traceroute doesn't work from B to A, it looks like that the B router doesn't know, where to send the packets.
Some router also allows the selection of biderectional tunnels, so they are able to configure both sides by exchaning routing information. But this works (if it works) usually only for routers from the same type or manufacturer.
As your devices are different, you may have to setup each side individually.
As you said, there was a tunnel before with ASA devices, and you replaced one site (A), it may be possible that the old tunnel configuration still exists on the other site (B) and this tunnel configuration doesn't have a counterpart and therefore sends everything into the nowhere.
So have a look at site B, if there is still am old VPN Tunnel / routing configuration to A, possibly you have to delete it and recreate it again. Sometimes it is just only needed to correct some settings.
Maybe your other VPN Tunnels give you a clou, what you have to setup on site B to route back to site A. As B is also connected to C,D,E, the settings for A should be similar just with different IP Adresses.
From the general perspective...
Router A has to know which targets are behind network B. Also router B has to know, which targets are bedind network A. Pring / tracert is the proof, that routing works fine.
The VPN tunnels still need to be controlled by firewall policy. Are you allowing traffic to reach SiteA from SiteB on firewall at SiteA? Do you see any drops in the firewall logs?
On pfSense there's no automatic NAT for IPSec tunnels, so it's unlikely to be that. The default is to NAT any traffic from the LAN port to the WAN port, so any traffic traversing the IPSec tunnel isn't included.
On pfSense there's no automatic NAT for IPSec tunnels, so it's unlikely to be that. The default is to NAT any traffic from the LAN port to the WAN port, so any traffic traversing the IPSec tunnel isn't included.
ASKER
I think I have this figured out. The strangest thing I've ever seen. So while I can telnet to port 21, 80, 9001 on the local subnet to the jetdirect, I can not across the tunnel. I turned on ICMP ability and had them ping the pfsense local IP and it pings fine. Turned off firewall on a windows PC and it also is able to ping fine across the tunnel. I can also telnet to 135 across the VPN to the workstation fine. The only thing that isn't working is the printer, so somehow that thing is jacked up. They are going to take a new jet direct printer card out there tomorrow as well as a new printer although I only suspect it to be the jet direct card as the issue. Still doesn't make sense how it doesn't work across the tunnel but does on the local subnet.. VERY STRANGE! I'll update this post tomorrow.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
You may be onto something there. The local IP of the old ASA may have been different. I do not know because it died and I had to go off of what was given to me. From Site C, I can telnet (23) to jet direct at Site C, Same for Site D, and E and access the Jet Direct settings. From Site A, I cannot access telnet (23) to the Site A jet direct to access that same menu of settings.
The weirdest thing was I kept focusing on the tunnel being the issue because I can telnet from Site A to Site A Jet Direct on 21, 80, and 9001 but couldn't across the tunnel. Today I disabled Windows Firewall temporarily on a workstation at Site A, and then asked Site B to ping the IP.... they could, then I asked them to telnet to 135/139 RPC/NETBIOS and they also could. So at this point I knew it was something with the JetDirect itself. I bet you are right and the jetdirect has a static IP with the OLD IP of the ASA as the gateway and it's different now... that makes this whole thing make a LOT MORE SENSE. I'm now doing a scan on the jetdirect ip of 1-65000 to see what ports are opened to see if I can get in to see what the settings are set to now since the default telnet port isn't working to get in and see it. I'll keep you posted.
The weirdest thing was I kept focusing on the tunnel being the issue because I can telnet from Site A to Site A Jet Direct on 21, 80, and 9001 but couldn't across the tunnel. Today I disabled Windows Firewall temporarily on a workstation at Site A, and then asked Site B to ping the IP.... they could, then I asked them to telnet to 135/139 RPC/NETBIOS and they also could. So at this point I knew it was something with the JetDirect itself. I bet you are right and the jetdirect has a static IP with the OLD IP of the ASA as the gateway and it's different now... that makes this whole thing make a LOT MORE SENSE. I'm now doing a scan on the jetdirect ip of 1-65000 to see what ports are opened to see if I can get in to see what the settings are set to now since the default telnet port isn't working to get in and see it. I'll keep you posted.
ASKER
I installed the HP Web JetAdmin tool that lets you manage jet direct devices... THE GATEWAY is WRONG as suggested. I tried to update it to the proper gateway and it throws an error. UGGH. At least I know that's what has been going on this entire time... I still can't believe I didn't think of that. Thanks for the help. I'm going to mess with this now and try to get the gateway fixed.
ASKER
Found an old version of java and httpd to jet direct. Tried to change there. Says settings saved but gateway reverts back after the change. I tried changing to DHCP and it says setting saved but reverts back to static with bad gateway. Gonna have them try directly from printer tomorrow.
Maybe the printer jumps back because DHCP enabled and gateway it set via DHCP scope settings? Or GPO
You may also check all other devices for the correct gateway.
Or you change the pfSense back to the old ip of the ASA, but not sure what impact this have.
You may also check all other devices for the correct gateway.
Or you change the pfSense back to the old ip of the ASA, but not sure what impact this have.
ASKER
It's not on DHCP, it's static. When I try to change to DHCP it just jumps back to static and reverts back to same IP.
The DHCP scope is correct on the network, all of the other clients on the network receive the proper gateway fine.
It's the card that's causing the issue. Luckily they have another jet direct card and they are going to swap it out for me so that I can telnet into it and update the IP that way. I am going to mark this as solved after I confirm this is working with your reply about the gateway on the jet direct being the issue. It's like a light bulb went off as soon as you said that it made all the weirdness I have been experiencing with this make sense.
Long story short, the IPSec tunnel is working fine with no special rules for NAT'ing like you suggested. The only rule I had to put in was a IPSec rule to allow traffic from Site B into Site A on the firewall/ipsec tab.
The DHCP scope is correct on the network, all of the other clients on the network receive the proper gateway fine.
It's the card that's causing the issue. Luckily they have another jet direct card and they are going to swap it out for me so that I can telnet into it and update the IP that way. I am going to mark this as solved after I confirm this is working with your reply about the gateway on the jet direct being the issue. It's like a light bulb went off as soon as you said that it made all the weirdness I have been experiencing with this make sense.
Long story short, the IPSec tunnel is working fine with no special rules for NAT'ing like you suggested. The only rule I had to put in was a IPSec rule to allow traffic from Site B into Site A on the firewall/ipsec tab.
ASKER
OK, update. I had them reboot the jet direct again for me and telnet magically is working on it now. I was able to set the gateway to the proper IP and now the solaris server at Site B can communicate with device and print to it fine.
Thanks again for mentioning the gateway as that got me going down the right rabbit hole to get it fixed.
Thanks again for mentioning the gateway as that got me going down the right rabbit hole to get it fixed.
Yea, sometimes it comes different, and second as you think. (german phrase). :-)+
There is always a logic behind it, sometimes not quite easy to find.
There is always a logic behind it, sometimes not quite easy to find.
The difference is mostly just conneted to the routing.
So the side, where you created the VPN tunnel may have got a route from A to B, but you have to make sure, that there is also a route on the other end which points from B to A. So possibly an additional configuration step on the remote side.