4. Problems with forwarding for videophone vp-200

Problems with forwarding for videophone vp-200

  • R

    I have a video phone - Soreneson vp-200, I forwarded the published ports but I get no video from the person I called.

    My setup is WAN -> pfSense -> LAN switch1 -> LAN switch2 -> videophone

    pfSense - 2.0.1 (x86) on Intel D2500CCE Mini-ITX (ATOM) 4GB (squid, lightsquid, ntop)
    switch1 is Netgear (gs608 v3) 10/100/1000
    switch2 is D-link (dgs-2205) 10/100/1000

    videphone requires 1720 and 15328-15348 TCP & UDP to be forwarded

    Lan = 192.168.1.0/24  Videophone ip = 192.168.1.40

    Forwards =
      If    Proto    Src. addr  Src. ports      Dest. Addr    Dest. ports        NAT IP         NAT Ports
    WAN  TCP/UDP      *            *          WAN address 15328 - 15348  192.168.1.40   15328 - 15348
    WAN  TCP/UDP      *            *          WAN address      1720          192.168.1.40       1720

    I captured 2 tcpdumps, one was from the WAN (em0) interface and the other from the LAN (em1) interface. I got no traffic on the WAN (em0) when I called out, I did get traffic when they attempted to call me. I got black screen (no video) of the call recipient on either attempt.

    WAN tcpdump - command: tcpdump -i em0 portrange 15328-15348 and port 1720

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
14:01:54.151164 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [s], seq 2126466617, win 5840, options [mss 1380,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop], length 0
14:01:54.151904 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [S.], seq 931972596, ack 2126466618, win 5840, options [mss 1460,nop,nop,sackOK], length 0
14:01:54.181890 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 1, win 5840, length 0
14:01:54.186050 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [P.], ack 1, win 5840, length 388
14:01:54.186792 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [.], ack 389, win 6432, length 0
14:01:54.211920 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [P.], ack 389, win 6432, length 204
14:01:54.225737 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [P.], ack 389, win 6432, length 236
14:01:54.243582 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 205, win 5636, length 0
14:01:54.255605 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 441, win 6196, length 0
14:01:54.260965 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [P.], ack 441, win 7504, length 219
14:01:54.300176 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [.], ack 608, win 7504, length 0
14:02:01.353203 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [P.], ack 608, win 7504, length 246
14:02:01.359521 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [P.], ack 608, win 7504, length 56
14:02:01.382951 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 687, win 7258, length 0
14:02:01.383659 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [P.], ack 608, win 7504, length 56
14:02:01.389362 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 743, win 7202, length 0
14:02:01.389486 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [P.], ack 743, win 8576, length 56
14:02:01.390175 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [.], ack 664, win 7504, length 0
14:02:01.391118 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [P.], ack 743, win 8576, length 56
14:02:01.391629 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [.], ack 720, win 7504, length 0
14:02:01.413329 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 799, win 8520, length 0
14:02:19.828548 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [P.], ack 720, win 7504, length 54
14:02:19.859615 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [.], ack 853, win 8522, length 0
14:02:19.929139 IP 65.37.251.24.15331 > 154.118-30-64.ftth.swbr.surewest.net.1720: Flags [F.], seq 720, ack 853, win 8576, length 0
14:02:19.968074 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [.], ack 721, win 7504, length 0
14:02:20.019967 IP 154.118-30-64.ftth.swbr.surewest.net.1720 > 65.37.251.24.15331: Flags [R.], seq 853, ack 721, win 7504, length 0

LAN tcpdump - command: tcpdump -i em1 portrange 15328-15348 and port 1720
[code]14:00:30.461693 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [s], seq 858992593, win 5840, options [mss 1460,sackOK,TS val 590575 ecr 0,nop,wscale 0], length 0
14:00:30.491829 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [S.], seq 41377998, ack 858992594, win 8192, options [mss 1380], length 0
14:00:30.492691 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [.], ack 1, win 5840, length 0
14:00:30.501993 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 1, win 5840, length 364
14:00:30.531941 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 365, win 7828, length 0
14:00:30.533229 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 365, win 64860, length 125
14:00:30.533735 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [.], ack 126, win 5840, length 0
14:00:30.549223 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 126, win 5840, length 56
14:00:30.554311 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 126, win 5840, length 56
14:00:30.578878 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 421, win 64804, length 0
14:00:30.579701 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 126, win 5840, length 236
14:00:30.583851 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 477, win 64748, length 0
14:00:30.609315 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 713, win 64512, length 0
14:00:31.823100 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 713, win 64512, length 53
14:00:31.832123 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 179, win 5840, length 52
14:00:31.861787 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 765, win 64460, length 0
14:00:36.850137 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 765, win 64460, length 53
14:00:36.859487 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 232, win 5840, length 52
14:00:36.889659 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 817, win 64408, length 0
14:00:41.874803 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 817, win 64408, length 53
14:00:41.883949 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 285, win 5840, length 52
14:00:41.913480 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 869, win 64356, length 0
14:00:46.900013 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 869, win 64356, length 53
14:00:46.909084 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 338, win 5840, length 52
14:00:46.938980 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 921, win 64304, length 0
14:00:51.922997 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 921, win 64304, length 53
14:00:51.932062 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 391, win 5840, length 52
14:00:51.961657 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 973, win 64252, length 0
14:00:56.947069 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 973, win 64252, length 53
14:00:56.955962 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 444, win 5840, length 52
14:00:56.985636 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 1025, win 64200, length 0
14:00:57.575915 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [P.], ack 1025, win 64200, length 77
14:00:57.594360 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [P.], ack 521, win 5840, length 57
14:00:57.607243 IP 192.168.1.40.15337 > tech.svrs.tv.1720: Flags [F.], seq 1082, ack 521, win 5840, length 0
14:00:57.611053 IP 192.168.1.40.15339 > 65.37.251.24.1720: Flags [s], seq 885110465, win 5840, options [mss 1460,sackOK,TS val 593277 ecr 0,nop,wscale 0], length 0
14:00:57.623884 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 1082, win 64143, length 0
14:00:57.636586 IP tech.svrs.tv.1720 > 192.168.1.40.15337: Flags [.], ack 1083, win 64143, length 0
14:00:57.641077 IP 65.37.251.24.1720 > 192.168.1.40.15339: Flags [S.], seq 1511642670, ack 885110466, win 5840, options [mss 1380,nop,nop,sackOK], length 0
14:00:57.641728 IP 192.168.1.40.15339 > 65.37.251.24.1720: Flags [.], ack 1, win 5840, length 0

Can anyone decipher the tcpdumps and maybe help?[/s][/s][/code][/s]
    0
  • I

    Can you post the actual capture files in the thread so that I can take a look in Wireshark?

    Can you also confirm that you've correctly configured the 'Public IP Address' setting on the VP-200 so that it's set to the actual and current public IP address of your WAN interface?

    If your WAN is using DHCP there could be a potential mismatch between the 'Public IP Address' on the VP-200 and your actual WAN address if the WAN address does change from time to time.

    0
  • R

    Thanks for the response!

    Will get the capture files, tonight.

    The public ip setting can be manually set on the vp-200 but protected by a code that is not supplied to me, however Sorenson tech support has manually set it on their end and it does show up in the vp-200 network settings.

    WAN is static, so this seems like a non issue(?), sorry should have posted that in the OP.

    EDIT:
    TIA inflamer, here is what I captured.

    I marked "Disable hardware checksum offload" on pfSense, because I viewed the tcpdump files in wireshark and noticed some "unreassembled packets" msgs and read it was likely due to offloading checksums, disabling the offloading eliminated those msgs. I have also removed squid, lightsquid, ntop (just in case).

    Here is the file, this was captured (using the command below) on the em1 (LAN) interface when I made a call from the vp-200, just a call and then hangup. There were no packets in the WAN interface file and no packets in either interface file when I made a call into the vp-200 (which is probably indicative of the "broke" nature of the connection(?)!  ;)

    I used the command:

    tcpdump -i em1 -w /root/dump.060612.em1.vpcallout -s 65535 portrange 15328-15348 and port 1720

    to create the capture file.

    dump.060612.em1.vpcallout.txt

    0
  • I

    Looking at the packet capture, it seems that your endpoint never attempts to open an H.245 channel towards the remote party.

    At 01:32:10, 174.137.37.16 sends an H225 CONNECT message to your device, specifying an H245 port of 55741. At this point, I would expect to see your endpoint creating a new TCP connection to this port, but this does not seem to happen.

    Instead, your endpoint seems to send two H225 INFORMATION messages towards the remote party, I'm unsure what the purpose of this is.

    Are you positive that your endpoint will use a source port in the range 15328-15348 for the H245 connection as well?

    0
  • R

    Sorry inflamer, I wish I could answer you better. I cut and pasted the following from the official doc:

    Inbound Ports: 
    Port 1720 (TCP & UDP) 
    Ports 15328-15348 (TCP & UDP)

    Outbound Ports: 
    Ports 1024-65535 (TCP & UDP)
    Port 21 (FTP) 
    Port 80 (HTTP)

    The VP-200 can be installed on a network using a public or private IP Address. Depending on which environment exists,
    the setup recommendations may differ.

    Public Environment:
    Assign the VP-200 a publicly routable IP Address. (best
    case scenario)

    NAT Environment:
    There are two scenarios:
    1.  Create a static IP Address mapping from a static
    private IP to a unique static public IP. (Allows for
    inbound and outbound calls.)
    2.  Assign or DHCP a private IP which resolves to a Non-
    unique IP. (Only allows for outbound calls.)

    Note: Both scenarios require the necessary ports
    mentioned above, to be open.

    0
  • R

    This has been fixed,

    I needed to create a static port so the source port is not rewritten. Static_Port

    BTW Thanks for your help inflamer for looking at the tcpdump! It is really appreciated!  ;D ;D ;D

    0
  • I

    Glad to hear it's resolved now.

    This should however work without static port NAT as long as the NATed endpoint on your end is aware of its public NAT address (and obviously if the endpoint has NAT support built in).

    • Andreas
    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy