Welcome, Guest. Please login or register.
Did you miss your activation email?
Tuesday 30 April 2024, 02:49:57 pm

Login with username, password and session length

Download the latest community FREE version  HERE
14247 Posts in 4376 Topics by 6493 Members
Latest Member: thiagodod
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  General Support
| | |-+  Allow inbound traffic on outside interface
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: Allow inbound traffic on outside interface  (Read 16560 times)
kwillacey
Jr. Member
*
Offline Offline

Posts: 5


« on: Tuesday 11 October 2011, 01:49:13 am »

Hi all I am wondering if someone can help me with my setup which is pretty simple.

LAN -------> EFW -------> Cisco router -------> ISP1 & 2

I have my public IP addresses on the router and a private IP address subnet between the EFW and the router and it works fine. Clients can browse the Internet and the EFW and router are setup to forward smtp traffic to the mail server on the LAN. However here is the issue, the Cisco router is configured with a remote access VPN. The VPN works as we can connect and login and access the subnet between the router and the EFW but we cannot access the subnets/LAN behind the EFW. I suspect the EFW is not allowing the VPN pool access to the internal network.

1. How can I confirm this is the case from the EFW?
2. How can I configure the EFW to allow the traffic?

Any help would be greatly appreciated, thanks.

Logged
kwillacey
Jr. Member
*
Offline Offline

Posts: 5


« Reply #1 on: Wednesday 12 October 2011, 01:43:58 am »

Can any expert take pity and help please. All I need to know is how to allow certain traffic to flow from the red interface to the green interface. It would be really appreciated!
Logged
kwillacey
Jr. Member
*
Offline Offline

Posts: 5


« Reply #2 on: Wednesday 12 October 2011, 05:42:40 am »

Is it port forwarding that should be done? Since I have it setup to allow inbound traffic for mail and http to my email server, do I simply setup a port forward that allows any port on a particular subnet that originates from the red zone to access the internal network on the green zone?
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #3 on: Wednesday 12 October 2011, 05:45:47 am »

By default EFW won't allow anything coming from RED, unless you create some incoming rule to allow it.
I never did anything like you need, I usually worked by creating a service on WAN, and redirecting a port to some IP:port, but not a LAN to LAN connection. This is intended to work on "controlled" zones: GREEN, ORANGE, BLUE and VPN.
You can try by creating some rules on "Port forwarding / Destination NAT" firewall, maybe using the "Do not NAT" option you can have some sucess on what you need.

On Cisco you probably need to add an static route to reach the LAN behind the Endian Firewall. Always make sure that the traffic goes like you expected (use traceroute a lot).

Try to read the docs fromEndian, to see if any option fits what you need:
http://docs.endian.com/firewall.html
Logged
kwillacey
Jr. Member
*
Offline Offline

Posts: 5


« Reply #4 on: Wednesday 12 October 2011, 06:18:06 am »

Thank you very much for your response. I only have one subnet on the internal network and routing does work as I do not perform NAT on the EFW for my server addresses, this is done on the router and they are able to browse fine. But if I try to connect to any device on the LAN from the router is does not work. Port forwarding does work as I can access web mail from the Internet and receive mail on port 25.

I was thinking port forwarding might be the solution but I can't seem to specify that the source and destination ports be 'any' for some reason it needs to be specific. How can I make the source and destination ports any?

Can it have anything to do with inter zone traffic? I will keep trying with port forwarding to see if I have any luck. Also what logs would you recommend I check?
Logged
kwillacey
Jr. Member
*
Offline Offline

Posts: 5


« Reply #5 on: Wednesday 19 October 2011, 01:31:14 am »

I have had zero luck trying to get this to work and I was wondering if the following could work. Currently there is no need for a dmz and assuming traffic can flow from the dmz to the internal network without any issues then I was thinking what if I created a dmz on the efw and connected it to the router on another subnet. Create a route on the efw that says to get to the vpn pool send it out the dmz interface, I would also create a rule to nat any host machine on my internal network to a different range of addresses when it tries to communicate with the vpn pool, that way when the router is sending the return traffic it will send it to the dmz interface as long as I add the route to do so rather than the outside interface. Conceptually it sounds OK to me but could that work?

1. For instance if my internal address is 1.1.1.1 and I try to browse to google or whatever the efw sends it to its default gateway out the red interface which is the router and it gets natted, the traffic returns and the router routes the traffic back to the efw and in turn to the host, which is a normal traffic flow.
2. Next someone connects via the VPN on the router and attempts to connect to a host on the internal network, however from the perspective of the VPN users the internal network is hidden, so in order to get to 1.1.1.1 they connect to 2.2.2.2. The router has a route that sends any traffic destined to 2.2.2.2 to the dmz interface of the efw, the efw then translates 2.2.2.2 to 1.1.1.1 and routes it to the host. The host responds and sends it to the efw, the efw routes the traffic destined to the VPN pool out the dmz interface and translates it to 2.2.2.2 thus preserving the flow of traffic.
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #6 on: Wednesday 19 October 2011, 10:58:37 am »

I have used VPN appliances on DMZ (=ORANGE), and they work without problems. Just as I said, be careful when you create the static routes, you must think on both ways. Ensure that the traffic can go from A to B, and from B to A. Otherwise you won't get a single ping (because there is no route back to reply the ping).

On Endian define that the VPN subnet is routed via Cisco's IP (must be ORANGE), just make sure is routed to the Cisco IP, not the Orange EFW IP.
 On Cisco router define that the GREEN subnet is reached via EFW's ORANGE IP.

Logged
juddyjacob
Full Member
***
Offline Offline

Posts: 64


« Reply #7 on: Thursday 20 October 2011, 01:58:09 pm »

Im not sure if I understand the purpose of the cisco device, as the endian firewall will route to multiple ISP circuts, support your VPN interfaces, and port forward whatever you need. To me it sounds as if there really is no need for the cisco router to be in place. But for whatever reason you might have, Im not sure that it will work behind the firewall as to my knowlege it was designed to be the end point device.  The DMZ mentioned before sounds like the best way to pull it off though, as I would be looking for ways to bypass the endian firewall all together in this situation. Just make sure you route all traffic from the cisco vpn tunells back to the cisco router.

I think you might also be able to accomplish this by giving the firewall a alias IP, You can try to Give it the same alias IP as your cisco router

Good luck! Smiley
Logged
timupci
Full Member
***
Offline Offline

Posts: 34


« Reply #8 on: Saturday 05 November 2011, 10:27:32 am »

Any reason why you are using the Cisco router for VPN and not using the EFW OpenVPN? Other Cisco VPN Hardware?

Here is my recommendation.



                           /------- RED 1 with External IP ------ \
LAN -------- EFW                                                              Cisco Router ------ 2 ISP ---------- OpenVPN User
                           \--------RED 2 with External IP ------ /
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.094 seconds with 18 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com