This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Transparent/split tunneling and return traffic

It seems that return traffic is not being sent back to my red device. At least I see the traffic coming from my device in the logs, but no return traffic. If I tracert to a device on the remote network the traffic hits the asg then a router on the internet. I have the red setup with transparent/split with dhcp so I do not know what the IP of the red device is without looking at the device the red is pulling the ip from and that seems like it should not be necessary to make all of this work. Any ideas? I am running 8.1 on my asg. I see some older posts out there, but they seem to be related to older versions and not relevant. I have also added a packet filter rule that allows the traffic from the red network onto my network. Is there something that needs to be configured going the other way? I can see that in interfaces there is a red interface, but not knowing the ip of the red device I cannot setup the interface.


This thread was automatically locked due to age.
  • Turn on ping visibility in the packet filter->icmp settings.

    Check out the DHCP Client interface on the RED "redsX" hardware under "Network->Interfaces". You should see there which IP the ASG pulled from the remote network.

    Can the remote clients now ping that IP address?

    In the other direction, can the ASG ping one of the client IPs in the remote network?

    Once that works, you can deal with traffic to other networks. Which IP the RED itself uses should not be relevant.

    /tom
  • If I go to Interfaces > Hardware there are only the three interfaces that all belong to my ASG. I do not see a red interface there. Am I looking in the wrong place? If I go to Support > Adavnced > Interfaces I see the following

    5: reds1:  mtu 1500 qdisc noqueue state UNKNOWN 
        link/ether 00:1e:01:f1:15:ba brd ff:ff:ff:ff:ff:ff

    If I go to the red overview I only see the public IP of the router that the red is sitting behind. I cannot see the private ip that the red was handed.

    I looked on the wireless router to which the red is connected (with a cable)  to find the ip 192.168.50.61. I added this interface to the asg with the ip 192.168.50.61/24 and now I can access the network behind the red and the ip phone connected to the red can make calls. 

    The problem is that when I box up the red and send it off to my remote user I do not want to have step him through finding the ip that his router is handing to the red. I thought  that the red setup was not supposed to require this type of interaction with the remote users.

    I would even think that I should not have to manually add the interface for the red. It would seem that this would happen dynamically. I guess we still need to figure out how to find the ip of the red without having to login to another router to find it.

    Thanks!
  • The other outstanding item is that I am not getting name resolution. For example: If on the red end my split domain name is xyz.com I would think that if I tried to connect to server.xyz.com it would use the split dns server to resolve that server ip. I can connect to server.xyz.com by ip, but not by name.
  • Ah [:)] Now I see what the problem is. You didn't add the RED using the "deployment helper", did you? That "helper" will automatically add an interface on the "reds1" hardware that uses DHCP client to pull an IP from the remote network. You have now added such an interface manually, but re-used the IP the RED got from the DHCP Server at the remote location.

    While this can work, it is a bit odd to have the same IP on the RED and on the ASG interface. You can either:

    - change the ASG-side interface to use DHCP client ("Cable Modem"), so it gets assigned an IP by the remote DHCP server
    - change the ASG-side interface to use any free IP from the remote network manually (it should not be from the remote DHCP server range)
  • On DNS: You may need to allow the traffic to the split DNS server in the packetfilter configuration (port 53 from the remote network).
  • Dynasty Lan designer LV handbags Broom did not plane notice nfl youth jerseys the acerbity." I'll go digest LV handbags discount a bath. "Yang Dynasty stood up high quality LV replica handbags  and walked to the room. Lan custom nfl jerseys Broom Yang Dynasty to look stake, the syncope vocalization.